P. 1
Software Project Management

Software Project Management

1.0

|Views: 517|Likes:
Slides of the software project management by Mr. M N Doja, Jamia Millia Islamia
Slides of the software project management by Mr. M N Doja, Jamia Millia Islamia

More info:

Published by: Sheel Sindhu Manohar on Mar 24, 2013
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

07/29/2015

pdf

text

original

Project Management

August 2007
Syllabus
Course Contents:

Introduction to Project Management: Project Management Life Cycle

Software Project Planning, Project Activities and Work Breakdown Structure

Project Management Plan, Project Scheduling and Tracking Techniques

Project Economics: Project Costing, Project Estimation Techniques,
Automated Estimation Tools

Risk Analysis and Management, Risk Mitigation and Management, Software Metrics and Project
Management

Project Control and Closure, Project Management Issues with regard to New Technologies

Suggested Readings:

1. Bob Hughes and Mike Cotterell, “Software Project Management”, Fourth Edition 2006, TMH
2. Pankaj Jalote, ―Software Project Management in Practice‖, 2002, Pearson Education Asia.
3. Software Project Management- A unified Approach, Walker Royce, Pearson Education
3. Robert T. Futrell, Donald F. Shafer, and Linda I.. Shafer, ―Quality Software Project Management‖
2002, Pearson Education Asia.
4. Ramesh Gopalaswamy, ―Managing Global Software Projects‖, 2003, Tata McGraw-Hill
What is a project?
Some dictionary definitions:
“A specific plan or design”

“A planned undertaking”

“A large undertaking e.g. a public works scheme”
Longmans dictionary

Key points above are planning and size of
task
What is a Project?
A project is a temporary endeavor undertaken to
create a unique product, service or result
Project Characteristics
1. Temporary every project has a definite beginning and a
definite end. The end is reached when the project‘s
objectives have been achieved or when it becomes
clear that the project objectives will not or cannot be
met and the project is terminated
– Temporary does not necessarily mean short in duration; many
projects last for several years. In every, case, however, the
duration of a project is finite; projects are not ongoing efforts
Project Characteristics contd..


2. A Project creates unique deliverables, which are products,
services or results

Projects can create:
• A product or artifact that is produced, is quantifiable, and can be either an
end item in itself or a component item
• A capability to perform a service, such as business functions supporting
production or distribution
• A result, such as outcomes or documents. For example, a research project
develops knowledge that can be used to determine whether or not a trend
is present or a new process will benefit society.

Uniqueness is an important characteristic of project deliverables
• The presence of repetitive elements does not change the fundamental
uniqueness of the project work.

3. Progressive Elaboration
• Developing in steps and continuing by increments
Project Objectives
To have a successful software project, the
project objectives should be clearly
defined
S – specific, that is, concrete and well-defined

M – measurable, that is, satisfaction of the
objective can be objectively judged
A – achievable, that is, it is within the power of the
individual or group concerned to meet the target
R – relevant, the objective must relevant to the true
purpose of the project
T – time constrained: there is defined point in
time by which the objective should be achieved
Projects vs Operational Work


Organizations perform work (task) to achieve a set of objectives.
Generally, work can be categorized as either projects or operations, although
the two sometimes overlap.

They share many of the following characteristics:
• Performed by people
• Constrained by limited resources
• Planned, executed, and controlled.

Projects and operations differ primarily in that operations are ongoing and
repetitive, while projects are temporary and unique.

The objectives of projects and operations are fundamentally different.

The purpose of a project is to attain its objective and then terminate.
Conversely, the objective of an ongoing operation is to sustain the
business.

Project concludes when its specific objectives have been attained, while
operations adopt a new set of objectives and the work continues.

Projects vs Operational Work
To Sum up
A task is more ‗project-like‘ if it is:
• Non-routine
• Planned
• Aiming at a specific target
• Work carried out for a customer
• Involving several specialisms
• Made up of several different phases
• Constrained by time and resources
• Large and/or complex
Are software projects really different from other projects?
Not really! …but…
• Invisibility
• Complexity
• Conformity
• Flexibility

make software more problematic to build
than other engineered artefacts.
What is management?
This involves the following activities:

• Planning – deciding what is to be done
• Organizing – making arrangements
• Staffing – selecting the right people for
the job
• Directing – giving instructions

continued…

What is management?
(continued)
• Monitoring – checking on progress

• Controlling – taking action to remedy hold-
ups

• Innovating – coming up with solutions when
problems emerge

• Representing – liaising with clients, users,
developers and other stakeholders
What is Project Management


Project management is the application of knowledge, skills, tools and
techniques to project activities to meet project requirements.

• Project management is accomplished through the application and
integration of the project management processes of initiating,
planning, executing, monitoring and controlling, and closing.

• The project manager is the person responsible for accomplishing the
project objectives

Managing a Project Includes:

• Identifying requirements
• Establishing clear and achievable objectives
• Balancing the competing demands for quality, scope, time and cost
• Adapting the specifications, plans, and approach to the different
concerns and
• expectations of the various stakeholders.

Project Management


Project Managers often talk of a ―triple constraint‖
• Project Scope
• Time and
• Cost

The relationship among these factor is such that if any one of the three factor
changes, at least one other factor is likely to be affected.

Project Managers also Manage projects in response to uncertainty
Project risk is an uncertain event or condition that, if it occurs, has a
positive or negative effect on at lease one project objective

The Project Management team has a professional responsibility to its
stakeholders including customers, the performing organization and the
public



Activities covered by project management
Feasibility study
Is project technically feasible and worthwhile from a
business point of view?
Planning
Only done if project is feasible
Execution
Implement plan, but plan may be changed as we go along
Project Management
Knowledge Areas
Project Management Knowledge Areas


Project Integration Management, describes the processes and activities that
integrate the various elements of project management, which are identified,
defined, combined, unified and coordinated within the Project Management
Process Groups. It consists of the Develop Project Charter, Develop
Preliminary Project Scope Statement, Develop Project Management Plan,
Direct and Manage Project Execution, Monitor and Control Project Work,
Integrated Change Control, and Close Project management processes.

Project Scope Management, describes the processes involved in ascertaining
that the project includes all the work required, and only the work required, to
complete the project successfully. It consists of the Scope Planning, Scope
Definition, Create WBS, Scope Verification, and Scope Control project
management processes.

Project Time Management, describes the processes concerning the timely
completion of the project. It consists of the Activity Definition, Activity
Sequencing, Activity Resource Estimating, Activity Duration Estimating,
Schedule Development, and Schedule Control project management
processes.
Project Management Knowledge Areas


Project Cost Management, describes the processes involved in planning,
estimating, budgeting, and controlling costs so that the project is completed
within the approved budget. It consists of the Cost Estimating, Cost Budgeting,
and Cost Control project management processes.

Project Quality Management, describes the processes involved in assuring that
the project will satisfy the objectives for which it was undertaken. It consists of
the Quality Planning, Perform Quality Assurance, and Perform Quality Control
project management processes.

Project Human Resource Management, describes the processes that organize
and manage the project team. It consists of the Human Resource Planning,
Acquire Project Team, Develop Project Team, and Manage Project Team
project management processes.

Project Communications Management, describes the processes concerning
the timely and appropriate generation, collection, dissemination, storage and
ultimate disposition of project information. It consists of the Communications
Planning, Information Distribution, Performance Reporting, and Manage
Stakeholders project management processes

Project Management Knowledge Areas


Project Risk Management, describes the processes concerned with conducting
risk management on a project. It consists of the Risk Management Planning,
Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk
Response Planning, and Risk Monitoring and Control project management
processes.

Project Procurement Management, describes the processes that purchase or
acquire products, services or results, as well as contract management
processes. It consists of the Plan Purchases and Acquisitions, Plan
Contracting, Request Seller Responses, Select Sellers, Contract
Administration, and Contract Closure project management processes.

Areas of Expertise Needed by the Project Team


Application Area Knowledge, Standards and Regulations
Application areas are categories of projects that have common
elements significant in such projects, but are not needed or
present in all projects. Application areas are usually defined in
terms of:

Functional departments and supporting disciplines, such as legal,
production and inventory management, marketing, logistics, and
personnel

Technical elements, such as software development or
engineering, and sometimes a specific kind of engineering, such
as water and sanitation engineering or construction engineering

Management specializations, such as government contracting,
community development, and new product development

Industry groups, such as automotive, chemical, agriculture, and
financial services.

Areas of Expertise Needed by the Project Team


•Understanding the Project Environment
Cultural and Social Environment
International and Political Environment
Physical Environment

•General Management Knowledge & Skills

•Interpersonal Skills
Effective Communication
Influencing the Organization
Leadership
Motivation
Negotiation and conflict Management
Problem Solving


Key points in lecture
• Projects are non-routine - thus uncertain

• The particular problems of projects e.g. lack of
visibility

• Clear objectives are essential which can be
objectively assessed

• Stuff happens. Not usually possible to keep
precisely plan – need for control

• Communicate, communicate, communicate!
Lecture 2
Review Lecture 1
What is a Project?
A Project is an endeavor to accomplish a
specific objective through a unique set of
interrelated tasks and the effective
utilization of resources.

Review Lecture 1
What are the attributes of a Project?
• A project has a well defined objective
• A Project is carried out through a series of
interdependent tasks
• A project utilizes various resources to carry out the
tasks
• A project has a specific time frame
• A project may be a unique or one-time endeavor
• A project has a customer
• Project involves a degree of uncertainity
Review Lecture 1
What are four factors that constrain the achievement of a
project Objective ?
Review Lecture 1 : What is Project Management


Project management is the application of knowledge, skills, tools and
techniques to project activities to meet project requirements.

• Project management is accomplished through the application and
integration of the project management processes of initiating,
planning, executing, monitoring and controlling, and closing.

• The project manager is the person responsible for accomplishing the
project objectives

Managing a Project Includes:

• Identifying requirements
• Establishing clear and achievable objectives
• Balancing the competing demands for quality, scope, time and cost
• Adapting the specifications, plans, and approach to the different
concerns and
• expectations of the various stakeholders.

Project Life Cycle
Project Life Cycle
Project Life Cycle
Phase 1 : Identification of Need

• Customer requesting proposals from individuals, a project team or
organizations to address the identified need or solve the problem.
The need and requirements are usually written up by the customer
in a document called a Request for Proposal (RFP)

• Through RFP, customer asks to submit proposals

• Not all situations involve a formal RFP

Project Life Cycle
Phase 2 : Develop a Proposed Solution
Submission of proposal(s) to the customer by one or
more individuals or organizations
After a customer evaluates the submissions and
selects the winning proposal, the customer and the
winning contractor negotiate and sign a contract
(agreement)
Phase 3 : Implementation of Proposed Solution
• Detailed planning for the project
• Implementing the Plan the plan to accomplish the
project objective

Project Life Cycle
Phase 4 : Terminating the Project
When a project is completed, certain close-out activities need to be
performed:
– Confirming that all deliverables have been provided to and
accepted by the customer
– All payments have been collected
– Evaluating performance of the project in order to learn what
could be improved if a similar project were to be carried out in
the future
– Obtain feedback from the customer to determine the level of
the customer‘s satisfaction and whether the project met the
customer‘s expectations.
– Obtain the feedback from the project team in the form of
recommendations for improving performance of projects in the
future
The Project Management Process
Project Management involves a process of first establishing a plan and
then implementing that plan to accomplish the project objective.
The Planning effort includes the following steps:
– Clearly define the project objective
– Divide and subdivide the project scope into major ―pieces‖ or work
packages by preparing work breakdown structure (WBS)
– Define the specific activities that need to be performed for each work
package in order to accomplish the project objective
– Graphically portray the activities in the form of a network diagram.
This diagram shows the necessary sequence and interdependencies
of activities to achieve the project objectives.
– Make a time estimate for how long it will take to complete each
activity.
– Make a cost estimate for each activity
– Calculate a project schedule and budget to determine whether the
project can be completed within the required time, with the allotted
funds and with the available resources.
Project Life Cycle
Phase 1 : Needs Identification
Need Identification
Need identification is the initial phase of the project life cycle. The customer
identifies a need, a problem or an opportunity for a better way of doing
something and therefore sees some benefit to undertaking a project that will
result in an improvement or advantage over the existing condition









This phase encompasses :
Identifying needs and selecting projects
Developing a request for proposal
The proposal solicitation process
Need Identification : Project Selection
Project Selection involves :
1. Evaluating various needs or opportunities
2. Deciding which of these should move forward as a project to be
implemented
3. Benefits and consequences need to be considered and evaluated.
They could be quantitative and qualitative, tangible and intangible

The Steps in project Selection are :
– Develop a set of criteria against which the opportunity will be
evaluated
– List assumptions that will be used as the basis for each opportunity
– Gather data and information for each opportunity to help ensure an
intelligent decision regarding project selection
• Preliminary Financial Estimates associated with each opportunity
• Gather information about each stakeholder
– Evaluate the opportunity against the criteria
Need Identification : Request for Proposal
The purpose of preparing a request for proposal is to state,
comprehensively and in details, what is required from the customer‘s
point of view, to address the identified need

A good RFP allows contractors or a project team to understand what
the customer expects so that they can prepare a thorough proposal that
will satisfy the customer‘s requirement at a realistic price

Need Identification : Request for Proposal
The purpose of preparing a request for proposal is to state,
comprehensively and in details, what is required from the customer‘s
point of view, to address the identified need

A good RFP allows contractors or a project team to understand what
the customer expects so that they can prepare a thorough proposal that
will satisfy the customer‘s requirement at a realistic price

Need Identification : Request for Proposal - Guidelines
1. An RFP must provide a statement of work (SOW)
A SOW deals with the scope of the project, outlining the tasks or work
elements the customer wants the contractor or project team to perform.
2. The RFP must include the customer requirements which define
specifications and attributes
3. The RFP should state what deliverable the customer expects the
contractor or project team to provide
4. The RFP should list any customer-supplied items.
5. The RFP might state the approvals required by the customer
6. Some RFPs mention the type of contract the customer intends to
use
7. An RFP might state the payment terms the customer intends to use
8. The RFP should state the reqwuired schedule for completion of the
project
9. The RFP should provide instructions for the format and content of
the contractor proposals
10. The RFP should indicate the due date by which the customer
expects potential contractors to submit proposals


Need Identification : Request for Proposal - Guidelines
11. An RFP may include the evaluation criteria. Criteria might include
1. The contractor‘s experience with similar projects
2. Technical approach proposed by the contractor
3. The schedule. Will the contractor be able to meet or beat the required
schedule?
4. The cost.
1. If the estimate is based on time and materials, are the costs
reasonable?
2. Have any items be left out
3. Does it appear that the contractor has submitted a low cost estimate
but will add costs after the project is under way, resulting in final costs
that are much higher than the original estimate?
12. In rare cases an RFP will indicate the funds the customer has
available to spend on the; project.




Need Identification : Soliciting Proposal
Once the RFP has been prepared, the customer solicits
proposals by notifying potential contractors that the RFP
is available.

One way for customers to do this is by identifying a selected group
of contractors in advance and sending each of them a copy of
the RFP
Another approach to soliciting potential contractor is for the
customer to advertise in certain business newspapers that the
RFP is available and give instructions on how interested
contractors can obtain a copy.

Proposed Solution
Proposed Solution
Lecture Learning
• Proposal marketing strategies and the bid/no-bid
decision
• The development of winning proposals
• The proposals preparation process and the elements
that may be included in a proposal
• Pricing considerations
• The evaluation of proposals
• Types of contracts between the customer and the
contractor
Proposed Solution : Bid / No Bid Decision
Competition
– Which other contractors might also submit a proposal in response to
the RFP?
– Do any of these contractors have a competitive advantage, because of
either pre-RFP marketing efforts or their previous work for or reputation
with the customer?
Risk
Is there a risk that the project will be unsuccessful – technically or
financially?
Mission
Is the proposed project consistent with the contractor‘s bhusiness mission
Extension of Capabilities
Would the proposed project provide the contractor with an opportunity to
extend and enhance its capabilities
Reputation
– Has the contractor successfully completed projects for the same
customer in the past or were the problems that left the customer
dissatisfied?
– Has the contractor unsuccessfully bid on RFPs from the customer in
the past?
Proposed Solution : Bid / No Bid Decision
Customer Funds
– Does the customer really have funds available to go forward with the
project? Or is the customer on a ―fishing expedition‖ – issuing an RFP
although unsure whether the project will ever be funded? A customer
may issue an RFP with the best of intentions but do so prematurely,
anticipating that the Board of Directors will approve funding. However, if
the company is having financial difficulties, the board may decide to
postpone the project indefinitely, even after proposals have been
received from interested contractors
Proposal Resource
– Are appropriate resources available to prepare a quality proposal? It is
not enough for a contractor to just prepare a proposal
– It is imperative that the proposal be of sufficient quality to have a good
chance of winning. To prepare a quality proposals, a contractor must
have the appropriate people – that is, resource – to work on it.
Project Resources
Are appropriate resource available to perform the project if the contractor
is selected as the winner? Contractors need to be sure that the
appropriate individuals within their organizations will be available to
work on the project.

9
Developing a Winning Proposal
• A selling document – not a technical report
• Convince the customer that you are the best one to solve the problem. That
is the contractor
– Understands what the customer is looking for
– Can carry out the proposed project
– Will provide the greatest value to the customer
– Is the best contractor to solve the problem
– Will capitalize on its successful experience with previous related projects
– Will do the work professionally
– Will achieve the intended results
– Will complete the project within budge and on schedule
– Will satisfy the customer
• Highlight the unique factors that differentiate you from competing
contractors
• Emphasize the benefits to the customer
• Write in a simple, concise manner
• Address requirements as laid out in the RFP
• Be realistic in scope, cost, and schedule
9
Developing a Winning Proposal
• A selling document – not a technical report
• Convince the customer that you are the best one to solve the problem. That
is the contractor
– Understands what the customer is looking for
– Can carry out the proposed project
– Will provide the greatest value to the customer
– Is the best contractor to solve the problem
– Will capitalize on its successful experience with previous related projects
– Will do the work professionally
– Will achieve the intended results
– Will complete the project within budge and on schedule
– Will satisfy the customer
• Highlight the unique factors that differentiate you from competing
contractors
• Emphasize the benefits to the customer
• Write in a simple, concise manner
• Address requirements as laid out in the RFP
• Be realistic in scope, cost, and schedule
10
Proposal Preparation
• Can be a straightforward task performed by one
person or a resource-intensive effort requiring a team
• May designate a proposal manager
• Schedule must allow time for review and approval by
management
• Can be a few pages or hundreds of pages
• Customers do not pay contractors to prepare
proposals
11
Proposal Contents
Proposals are organized into three sections:
• Technical Section
• Management Section
• Cost Section

11
Proposal Contents : Technical Section
The objective of the technical section of the contractor proposal is to convince the
customer that the contractor understands the need or problem and can provide the
least risky and most beneficial solution.
The elements of the Technical Section are
1. understanding of the problem
– Contractor thoroughly understands the problem to be solved
– Establish the basis for the solution proposed later in the technical section
2. proposed approach or solution
– A description of how the contractor would collect, analyze and evaluate data and information about the
problem
– Methods that would be used by the contractor to evaluate alternative solutions or further develop the
proposed solution to the problem
– The rationale for the proposed approach or solution. This rationale could be based on experiments
previously conducted by the contractor, the contractor's experience in solving similar problems or a
unique patented technology the contractor would use to solve the problem
– Confirmation that the proposed solution or approach would meet each of the physical, operational and
performance requirement stated in the customer's RFP
11
Proposal Contents : Technical Section
3. benefits to the customer
• The contractor should state how the proposed solution or approach would
benefit the customer.
• Benefits could be quantitative or qualitative and could include cost savings;
reduced processing time; reduced inventory; better customer service; less
scrap, rejects or errors, ; improved safety conditions; more timely information
and reduced maintenance
• This portion of the proposal should help convince the customer of the value of
the proposed approach compared with proposals from competing contractors

12
Proposal Contents : Management Section
Objective
to convince the customer that the contractor can do the proposed
work and achieve the intended results
The Management Section should contain the following elements:

– description of work tasks
– deliverables
– project schedule
– project organization
– related experience
– equipment and facilities


13
Proposal Contents : Cost Section
The objective of the cost section of the contractor proposal is to convince the
customer that the contractor’s price for the proposed project is realistic
and reasonable.

The cost section usually consist of
• Labor :
– estimated costs of the various classifications of people who are expected to work on
the project.
– It might include the estimate hours and hourly rate for each person or classification
– The estimates should be realistic
• Materials
• subcontractors and consultants
• equipment and facilities rental
• travel
• documentation
• Overhead
– Contractor will add a percentage to costs in items above to cover their
normal overhead – the indirect costs of doing business, such as insurance,
depreciation, accounting, general management, marketing and human
resources
• escalation
• contingency or management reserve
• fee or profit
14
Pricing Considerations
Be careful not to overprice or underprice the proposed project

Consider:
• reliability of the cost estimates
– Does the total cost of the proposed project is complete and accurate?
– Costs should be based on a recent similar project or, in the case of materials cost
estimates, on current price lists, catalogues or quotations.
• Risk
– If the project involves an endeavor that has not been undertaken before, such as
R&D, it may be necessary to include a large amount or contingency or
management reserve funds.
• value of the project to the contractor
• customer’s budget
– Pre-RFP marketing may help to know the customer budget
• Competition

15
Proposal Submission and Follow-Up
• Submit proposals on time
• Hand deliver expensive proposals or send 2 sets by different
express mail services, if necessary
• Continue to be proactive even after submission
16
Customer Evaluation of Proposals
• Some look at the prices and select only from the three
lowest-priced proposals
• Some screen out prices above budget or whose
technical section doesn’t meet all the requirements
• Some create a proposal review team that uses a
scorecard
• May submit a best and final offer (BAFO)
17
Customer Evaluation of Proposals (Cont.)
• Criteria that might be used in evaluating:
– compliance with SOW
– understanding of the problem or need
– soundness of the proposed approach
– contractor’s experience and past success
– experience of key individuals
– management capability
– realism of the schedule
– price – reasonableness, realism, and completeness
After selecting a contractor, a contract must be signed between
the customer and the contractor
A contract is:
• A vehicle for establishing customer-contractor
communications and arriving at a mutual understanding and
clear expectations
• An agreement between the contractor, who agrees to provide
a product or service, and the customer, who agrees to pay
• Must clearly spell out the deliverables
• Two types of contracts: fixed price and cost reimbursement
18
Types of Contracts
19
Types of Contracts (Cont.)
Fixed-price contract
• Price remains fixed unless the customer and
contractor agree
• Provides low risk for the customer
• Provides high risk for the contractor
• Is most appropriate for projects that are well defined
and entail little risk
20
Types of Contracts (Cont.)
Cost-reimbursement contract
• Provides high risk for the customer
• Provides low risk for the contractor
• Is most appropriate for projects that involve risk
• Customer usually requires that the contractor
regularly compare actual expenditures with the
proposed budget and reforecast cost-at-completion
21
Contract Provisions
Misrepresentation of costs - states that it is illegal for the contractor to
overstate the hours or costs expended on the project.
Notice of cost overruns or schedule delays - outlines the
circumstances under which the contractor must notify the customer
any schedule delays.
Approval of subcontractor - indicates when the contractor needs to
obtain approval before hiring a subcontractor.
Customer-furnished equipment or information - lists the items that
the customer will provide to the contractor throughout the project and
the dates by which the customer will make these items available.
Patents - covers ownership of patents that may result from conducting
the project.
Disclosure of proprietary information - prohibits one party from
disclosing project confidential information, technologies, or processes.
Termination - states the conditions under which the customer can
terminate the contract, such as nonperformance by the contractor
21
Contract Provisions
• Terms of payment - addresses the basis on which the customer will
make payments to the contractor.
• Bonus/penalty payments - some contracts have a bonus provision,
whereby the customer will pay the contractor a bonus if the project
is completed ahead of schedule or exceeds other customer
performance requirements. On the other hand, some contracts
include a penalty provision, whereby the customer can reduce the
final payment to the contractor if the project is not completed on
schedule or if performance requirements are not met.
• Changes. Covers the procedure for proposing, approving, and
implementing changes to the project scope or schedule.
Project Management Processes
Project Management Process
• Project management is an integrative endeavor — an
action, or failure to take action, in one area will usually
affect other areas.
• The interactions may be straightforward and well-
understood, or they may be subtle and uncertain.
• For example, a scope change will almost always affect
project cost, but it may or may not affect team morale or
product quality.
Project Management Process
• Projects are composed of processes. A process is "a series of
actions bringing about a result"
• Project management processes can be organized into five following
groups


(Arrows represent
flow of documents
and documentable
items)
Project Management Process
Executing
Processes

Level
of
Activity
Phase
Start
Time Phase
Finish


Planning
Processes
Closing
Processes
Initiating
Processes
Overlap of Process Groups in a Phase
1. Initiating a process
• Initiation – Committing the organization to begin the next phase
of the project
2. Planning a Processes
• Planning is of major importance to a project because the project
involves doing something which has not been done before.
• As a result, there are relatively more processes in this section.
However, the number of processes does not mean that project
management is primarily planning
• The amount of planning performed should be commensurate with the
scope of the project and the usefulness of the information developed.
• The relationships among the project planning processes are shown in
Figure on next slide
• These processes are subject to frequent iterations prior to completing
the plan. For example, if the initial completion date is unacceptable,
project resources, cost, or even scope may need to be redefined.
• In addition, planning is not an exact science—two different teams
could generate very different plans for the same project.

2. Planning process : Core processes
• Some planning processes have clear dependencies that require
them to be performed in essentially the same order on most
projects. For example, activities must be defined before they can be
scheduled or costed. These core planning processes may be
iterated several times during any one phase of a project. They
include:
• Scope Planning — developing a written scope statement as the
basis for future project decisions.
• Scope Definition — subdividing the major project deliverables into
smaller, more manageable components.
• Activity Definition - identifying the specific activities that must be per
formed to produce the various project deliverables
• Activity Sequencing —identifying an documenting interactivity
dependencies.
• Activity Duration Estimating — estimating the number of work
periods which will be needed to complete individual activities
2. Planning process : Core processes
• Schedule Development —analyzing activity sequences, activity
durations, and resource requirements to create the project schedule.
• Resource Planning —determining what resources (people,
equipment, materials) and what quantities of each should be used to
perform project activities.
• Cost Estimating —developing an approximation (estimate) of the
costs of the resources needed to complete project activities.
• Cost Budgeting —allocating the overall cost estimate to individual
work items.
• Project Plan Development —taking the results of other planning
processes and putting them into a consistent, coherent document
2. Planning process : Facilitating processes
• Interactions among the other planning processes are more
dependent on the nature of the project.
– For example, on some projects there may be little or no identifiable
risk until after most of the planning has been done and the team
recognizes that the cost and schedule targets are extremely
aggressive and thus involve considerable risk.
Although these facilitating processes are performed
intermittently and as needed during project planning, they
are not optional. They include:
– Quality Planning —identifying which quality standards are relevant
to the project and determining how to satisfy them.
– Organizational Planning —identifying, documenting, and assigning
project roles, responsibilities, and reporting relationships.
– Staff Acquisition —getting the human resources needed assigned
to and working on the project.
– Communications Planning —determining the information and
communications needs of the stakeholders: who needs what
information, when will they need it, and how will it be given to them
2. Planning process : Facilitating processes
– Risk Identification —determining which risks are likely to affect
the project and documenting the characteristics of each.
– Risk Quantification —evaluating risks and risk interactions to
assess the range of possible project outcomes.
– Risk Response Development —defining enhancement steps for
opportunities and responses to threats.
– Procurement Planning —determining what to procure and
when.
– Solicitation Planning —documenting product requirements and
identifying potential sources
3. Executing Processes
• The executing processes include core processes and facilitating
processes as described Planning Processes .Figure on the next
slide illustrates how the following processes interact:

– Project Plan Execution —carrying out the project plan by performing
the activities included therein.
– Scope Verification —formalizing acceptance of the project scope.
– Quality Assurance —evaluating overall project performance on a
regular basis to provide confidence that the project will satisfy the
relevant quality standards.
– Team Development —developing individual and group skills to
enhance project performance.
– Information Distribution —making needed information available to
project stakeholders in a timely manner.
– Solicitation —obtaining quotations, bids, offers, or proposals as
appropriate.
– Source Selection — choosing from among potential sellers.
– Contract Administration —managing the relationship with the seller
Information
Distribution
Quality
Assurance
Team
Development
Quality
Assurance
Source
Selection
Solicitation
Scope
Verification
Contract
Administration
4. Controlling Processes
• Project performance must be measured regularly to identify
variances from the plan.
• Variances are fed into the control processes in the various
knowledge areas. To the extent that significant variances are
observed (i.e., those that jeopardize the project objectives),
adjustments to the plan are made by repeating the appropriate
project planning processes.
• For example, a missed activity finish date may require adjustments
to the current staffing plan, reliance on overtime, or tradeoffs
between budget and schedule objectives.
• Controlling also includes taking preventive action in anticipation of
possible problems.
Controlling Processes
• The controlling process group contains core processes and
facilitating processes as described in Planning Processes. Figure on
the next slide illustrates how the following processes interact:

– Overall Change Control —coordinating changes across the entire
project.
– Scope Change Control —controlling changes to project scope.
– Schedule Control —controlling changes to the project schedule.
– Cost Control —controlling changes to the project budget.
– Quality Control —monitoring specific project results to determine if
they comply with relevant quality standards and identifying ways to
eliminate causes of unsatisfactory performance.
– Performance Reporting —collecting and disseminating performance
information. This includes status reporting, progress measurement, and
forecasting.
– Risk Response Control —responding to changes in risk over the course
of the project.
Performance
Reporting
Overall
Change Control
Scope
change Control
Schedule
Control
Cost
Control
Quality
Control
Risk
Response Control
Closing Processes
Contract Close-out —completion and settlement of the contract,
including resolution of any open items.
Administrative Closure —generating, gathering, and disseminating
information to formalize phase or project completion
Customizing Process Interactions
• The processes identified and their interactions meet the test of
general acceptance—they apply to most projects most of the time.
However, not all of the processes will be needed on all projects, and
not all of the interactions will apply to all projects.
• For example: An organization that makes extensive use of
contractors may explicitly describe where in the planning process
each procurement process occurs.
• The absence of a process does not mean that it should not be
performed. The project management team should identify and
manage all the processes that are needed to ensure a successful
project.
• Projects which are dependent on unique resources (commercial
software development, biopharmaceuticals, etc.) may define roles
and responsibilities prior to scope definition since what can be done
may be a function of who will be available to do it.
• Some process outputs may be predefined as constraints. For
example, management may specify a target completion date rather
than allowing it to be determined by the planning process.
Customizing Process Interactions
• Larger projects may need relatively more detail. For example, risk
identification might be further subdivided to focus separately on
identifying cost risks, schedule risks, technical risks, and quality
risks.
• On subprojects and smaller projects, relatively little effort will be
spent on processes whose outputs have been defined at the project
level (e.g., a subcontractor may ignore risks explicitly assumed by
the prime contractor) or on processes that provide only marginal
utility (there may be no formal communications plan on a four-person
project).
• When there is a need to make a change, the change should be
clearly identified, carefully evaluated, and actively managed

Planning
2 2 2
Learning Objectives
- Clearly define the project Plan and objective
- Develop a work breakdown structure
- Develop a network diagram
- CASE STUDY : Utilize a project management
methodology called the systems development
life cycle for information systems development
projects
3 3 3
Real World Example
• The Olympics
• Athens, Greece received the award to host the 2004 Olympic
Games in 1997
• Project work did not begin until 2000, after a warning was issued
by the International Olympic Committee. $1.19 billion was
added to the project cost because of construction delays and the
need for increased security
• Less than 100 days remained, and it appeared that most
construction projects would not be complete until a few days
before the games
• Olympic project team worked under a very tight time schedule,
with little time for independent tasks. Network planning
techniques are essential in these situations to define hierarchy of
projects
• A project manager can help team members to stay on task with
short-term goals to assure that the long-term goals are met on
time
2 2 2
Project Plan
The project plan is a formal, approved document used to
manage and control project execution. It Includes :
– Project charter.
– A description of the project management approach or strategy (a summary
of the individual management plans from the other knowledge areas).
– Scope statement, which includes the project deliverables and the project
objectives.
– Work breakdown structure (WBS) to the level at which control will be
exercised.
– Cost estimates, scheduled start dates, and responsibility assignments to
the level of the WBS at which control will be exercised.
– Performance measurement baselines for schedule and cost.
– Major milestones and target dates for each.
– Key or required staff.
– Key risks, including constraints and assumptions, and planned responses
for each.
– Subsidiary management plans, including scope management plan,
schedule management plan, etc.
– Open issues and pending decisions.
2 2 2
Project Plan : Purpose
- A project Plan is used to :
- Guide project Execution
- Document Project Planning assumptions
- Document Project Planning decisions regarding
alternatives chosen
- Facilitate communication among stakeholders
- Define key management review as to content,
extend and timing
- Provide a baseline for progress measurement and
project control
6
Work Breakdown Structure (WBS)
• The second step is to determine what activities need to be performed.
– Approaches
• Small Projects : Brainstorm
• Complex Projects : WBS
• A list of all the activities must be developed.
• The WBS is a hierarchical tree of end items to be accomplished.
• A work item is one small piece of the project.
• A work package is the lowest-level item.
• Criteria for deciding the ―How Many Levels in WBS
– The level at which a single individual or organization can be
assigned responsibility and accountability for accomplishing the
work package
– the level at which you want to control the budget and monitor and
collect cost data during the project.
Work Breakdown Structure for Festival Project
7
Responsibility Matrix
• Displays in tabular format the individuals
responsible for accomplishing the work items in
WBS.
• It is a useful tool because it emphasizes who is
responsible for each work item and shows each
individual‘s role in supporting the overall project
• ―X‖ can be used to indicate who is responsible.
• ―P‖ indicates who has primary responsibility.
• ―S‖ indicates who has secondary responsibility.
Responsibility Matrix for Festival Project
8
Activities, Defined
• An activity is a piece of work that consumes time.
• It does not necessarily require the expenditure of effort
by people
– For example: waiting for concrete to harden can take several
days but does not require any human effort
• For work package ― Game Booths‖ in WBS the
following eight detailed may be identified.
1.Design
Booths
2.Specify
material
3.Buy Material 4.Construct
Booths
5.Paint Booths 6.Dismantle
Booths
7.Move booths to
festival site
and
reassemble
8.Dismantle
booths and
move to
storage
9
Developing the Network Plan
• After all activities have been defined, they are
graphically portrayed in a network diagram that
shows the appropriate sequence and
interrelationships needed to accomplish the
overall project work scope.
• Two network planning techniques were developed
in the 1950‘s:
– Program evaluation and review technique
(PERT)
– Critical path method (CPM)
• Network Diagram shows the sequential flow and
interrelationships of activities.
10
Gantt Charts
• Gantt charts, or bar charts, are popular due to
their simplicity.
• The Gantt Charts combines the two functions of
planning and scheduling
– Activities are listed down the left-hand side.
– A time scale is shown along the bottom.
– The estimated duration for each activity is indicated by a
line or bar spanning the period during which the activity
is expected to be accomplished
– Column that indicate who is responsible for each task
can be added to the chart.
• With Gantt Charts, the scheduling of activities
occurs simultaneously with their planning


11
Gantt Charts (Cont.)
• Do not display the interrelationships of activities.
• If one activity is delayed, it is not obvious how
that will affect other activities.
• Most project management software can show
interdependencies with arrows.

Gantt Chart for Consumer Market Study Project
Network Diagram Techniques
• Network Techniques separate the planning and
scheduling functions
• A Network Diagram is the result or output of the
planning functions and is not drawn to a time
scale
• From this diagram a schedule is developed.
– Separating the two functions makes it much easier to
revise a plan and calculate an updated schedule
• Different formats can be used to draw the
Network diagram:
– Activity in the box (AIB) OR Activity on the
node (AON)
– Activity on the arrow (AOA)
13
Activity in the Box (AIB)
• Each activity is represented by a box.
• The activity description is written in the box.



• Activity consume time, and their description
usually starts with a verb
• Each activity is represented by one and only one
box.
• Each box is assigned a unique activity number.
• Activities have a precedential relationship.
• Some activities may be done concurrently.
Get
Volunteers
7
AIB : Sequential and Concurrent Activities
Wash Car
3
Dry Car
4
Get
Volunteers
7
Buy
Materials
8
Construct
Booth
9
Paint
Booth
10
Dismantle
Booth
11
Clean Up
12
14
Activity on the Arrow (AOA)
• Each activity is represented by an arrow.
• The activity description is written above the arrow.


• Each activity is represented by one and only one arrow
• The tail of the arrow designates the start of the activity.
• The head of the arrow designates the completion of the
activity.
• The length and slope of the arrow are in no way
indicative of the activity‘s duration or importance
Collect Data
15
Activity on the Arrow (AOA) (Cont.)
• Activities are linked by circles called events.
• An event represents the finish of activities entering it and the start of
activities leaving it.
• Each event is assigned a unique activity number.
• For example, the activities shown below, ―Wash Car‖ and ―Dry Car‖,
have a serial relationship and are linked together by event 2. Event
2, represents the completion of ―Wash Car‖ and the start of ―Dry Car‖
1 2 3
Wash Car Dry Car
The event at the beginning (tail of the arrow) of the activity
is known as the activity’s predecessor event, and the event
at the end (head of the arrow) of the activity is known as
the activity’s successor event
15
Activity on the Arrow (AOA) (Cont.)
• All activities going into an event (circle) must be finished before any
activities leading from that event can start.
12
8
11
Get
Volunteers
Construct
Booth
7
9
10
6
Buy
Materials
Paint
Booth
Dismantle
Booth
Clean Up
• Rules:
• Each event (circle) in the network diagram must have a unique event
number – that is, not two events in the network diagram can have the
same event number
• Each activity must have a unique combination of predecessor and
successor event numbers
16
Dummy Activities
• In the activity-on-the-arrow format, there is a special type of activity
known as a dummy activity, which consumes zero time and is
represented by a dashed arrow in the network diagram
• Used only in the activity-on-the-arrow format for two reasons
– To help in the unique identification of activities and to show certain
precedential relationships that otherwise could not be shown.
• Used in the AOA format.
• Consumes zero time.
• Represented by a dashed arrow.
• Needed for:
– Helping in the unique identification of activities.
– Showing certain precendential relationships that otherwise
could not be shown.
16
Dummy Activities
• Activities A and B below both have the
predecessor-successor event number
combination 1 – 2.




• This is not allowed in an AOA network
diagram, because if someone referred to
activity 1-2, it would not be clear whether
activity A or activity B was being discussed

1 3
A
B
16
Dummy Activities
• The insertion of a dummy activity, as shown
below, allows activities A and B to have
unique predecessor-successor event number
combinations.





1 3
2
A
B
16
Dummy Activities
• For example Draw AOA: Activities A an B
can be done concurrently. When activity A is
finished, activity C can start. When both
activity A and activity B are finished, activity D
can start






1 3
A
5
C
2 4
B
6
D
A
2
1
B
5
4
3
C
D
Incorrect
16
Dummy Activities
• An advantage of the Activity-in-the-box format
is that the logic can be shown without the use
of dummy activities.





A
1
C
3
B
2
D
4
17
Loops
• Not allowed because it portrays a path of
activities that perpetually repeats itself.
A
1
C
3
D
4
18
Laddering
• Used for projects that have a set of activities
that are repeated several times.

For example, consider a project involving the
painting of three rooms. Painting each room
requires
(1) preparing the room to be painted
(2) painting the ceiling and walls and
(3) painting the trim.
Assume that three experts will be available – one to
do the preparation, one to paint the ceilings and
walls and one to do the trim.
Activities Performed Serially
Activities Performed Concurrently
Concurrent processing is not possible in this case, as only one
expert is available for each type of activity
Laddering
19
Preparing the Network Diagram
• Ask the following questions regarding each
activity:
– Which activities must be finished immediately
before this activity can be started?
– Which activities can be done concurrently with
this activity?
– Which activities cannot be started until this
activity is finished?
20
Preparing the Network Diagram (Cont.)
• Should flow from left to right.
• Not drawn to a time scale.
• Can vary in how detailed the diagram should
be.
• AIB vs. AOA is a matter of personal
preference.
• AIB is the most common in project
management software packages.
20
Guidelines for Preparing the Network Diagram
• If a work breakdown structure has been
prepared for the project, then activities should
be identified for each work package.
• For example, figure on next slide shows a
WBS for a project involving a consumer
market study and the activities that have been
identified for each work package
Work Breakdown Structure for Consumer Market Study Project
20
Guidelines for Preparing the Network Diagram (contd…)
• It may be preferable to draw a summary-level network
first and then expand it to a more detailed network.
– A summary network contains a small number of higher-level
activities rather than a large number of detailed activities.
• The level of detail may be determined by certain
obvious interface or transfer points :
– If there is a change in responsibility – that is, a different person
or organization takes over responsibility for continuing the
work – it should define the end of one activity and the start of
other activities
• For example, if one person is responsible for building an item and
another person is responsible for packaging it, these should be
two separate activities.
20
Guidelines for Preparing the Network Diagram (contd…)
• Activities should not be longer in estimated duration
than the time intervals at which actual project progress
will be reviewed and compared to planed progress.
– For example, if the project is a three-year endeavor and the
project team plans to review project progress monthly, then the
network should contain no activities with estimated durations
greater than 30 days.
– If there are activities with longer estimated durations, they
should be broken up into more detailed activities with durations
of 30 days or less
• Finally, when the entire network diagram has been
drawn, it‘s necessary to assign a unique activity
number to each activity
Example : Network Diagram for Consumer Market Study Project
21
Exercise
Draw a network diagram representing the following logic:
As the project starts, activities A and B can be performed
concurrently. When A is finished, activities C and D can start. When B
is finished, activities E and F can start. When activities D and E are
finished, activity G can start. The project is complete when activities
C, F, and G are finished. Use both the activity-in-the-box and the
activity-on-the-arrow formats .
A
C
D
B E G
F
Start
Finish
21
Exercise
Activity Immediate Predecessor
1. Problem Definition —
2. Study Current System 1
3. Define User Requirements 1
4. Logical System Design 3
5. Physical System Design 2
6. System Development 4, 5
7. System Testing 6
8. Convert Database 4, 5
9. System Conversion 7, 8
1


2 5 6 7 9
3 4 8
21
Exercise
Draw a network diagram representing the following
logic:
• As the project starts, activities A and B can be
performed concurrently. When A is finished,
activities C and D can start. When B is finished,
activities E and F can start. When activities D and E
are finished, activity G can start. The project is
complete when activities C, F, and G are finished.
Use both the activity-in-the-box and the activity-on-
the-arrow formats .
21
Information System, Defined
• An information system (IS) is a computer-based
system that accepts data as input, processes the
data, and produces useful information for users.
22
Planning for Information Systems Development
• The systems development life cycle (SDLC) is
used to help plan, execute and control IS
development projects.
• Many people view the SDLC as a classic
problem-solving approach.
23
Steps of the SDLC
• Problem definition
• System analysis
• System design
• System development
• System testing
• System implementation
24
Project Management Software
You are advised to prepare the following
• WBS
• Responsibility Matrix
• Gant Chart
• Network Diagram





Scheduling
2 2 2
Learning Objectives
- Estimate the duration for each activity
- Establish the estimated start time and required
completion time for the overall project
- Calculate the earliest times at which each activity
can start and finish, based on the project‘s
estimated start time
- Calculate the latest times by which each activity
must start and finish in order to complete the
project by its required completion time
- Determine the amount of positive or negative slack
- Identify the critical (longest) path of activities

4
Real World Example
US Census 2000 Project
• A US Census takes place every 10 years in the form of a questionnaire from the
US Census Bureau. Census information helps the government in making
policies regarding health, education, transportation, community services etc.
• Census participation takes only a few minutes, but it takes years for the
employees of the Census Bureau. Census 2000 was a 13-year project that’s total
life cycle cost $65 billion
• Planning for data collection is important. 520 local census offices across the US
verify and collect as many addresses as possible
• Project’s goal was 70% response rate to the 2000 Census. The Bureau
implemented a plan to spread the word about the census and stress its
importance. A non-response plan was also established to reach those that failed
to complete the census
• The 2000 Census was considered to be the most accurate population count in
US history. For the first time, census data was made available on the Internet


6
Activity Duration Estimates
– The first step in scheduling is to estimate how long each activity will take.
– The duration estimate is the total elapsed time for the work to be done PLUS
any associated waiting time.
– The person responsible for performing the activity should help make the
duration estimate. However, for large projects it may not be practical to have
each person provide activity duration estimates.
– An activity’s duration estimate must be based on the quantity of resources
expected to be used on the activity.
Network Diagram for Consumer Market Study Project,
Showing Duration Estimates
7
Project Start and Finish Times
• It is necessary to select an estimated start time and a
required completion time for the overall project.
• The project‘s required completion time is normally part of
the project objective and stated in the contract.
• If a project must be completed in 130 working days, we
define the project‘s estimated start time as 0 and its
required completion time is day 130.
8
Schedule Calculations
• A project schedule includes:
– the earliest times (or dates) at which each
activity can start and finish, based on the
project's estimated start time (or date)
– the latest times (or dates) by which each
activity must start and finish in order to
complete the project by its required
completion time (or date)
9
Earliest Start and Finish Times
• Earliest start time (ES) is the earliest time at which a
particular activity can begin.
• Earliest finish time (EF) is the earliest time by which a
particular activity can be completed.
• EF = ES + Duration Estimate
• The ES and EF times are determined by calculating
forward through the network diagram.
• Rule: 1
– The earliest start time for a particular activity must be the same
as or later than the latest of all the earliest finish times of all the
activities leading directly into that particular activity
Earliest Start Times
Network Diagram for Consumer Market Study Project,
Showing Earliest Start and Finish Times
The ES and EF times are sometimes listed in a separate schedule table
11
Latest Start and Finish Times
• Latest finish time (LF) is the latest time by which a particular activity
must be finished in order for the entire project to be completed by its
required completion time, calculated on the basis of the project‘s
required completion time and the duration estimates for succeeding
activities.
• Latest start time (LS) is the latest time by which a particular activity
must be started in order for the entire project to be completed by its
required completion time, calculated by subtracting the activity‘s
duration estimate from the activity‘s latest finish time:
• LS = LF – Duration Estimate
• The LF and LS times are determined by calculating backward
through the network diagram.
• Rule 2: The latest finish time for a particular activity must be the
same as or earlier than the earliest of all the latest start times of all
the activities emerging directly from that particular activity.
Latest Finish Times
12
Network Diagram for Consumer Market Study Project,
Showing Latest Start and Finish Times
Latest Start and Finish Times
• The very first activity, ―Identify Target Consumers,‖ has
an LS of –8! This means that in order to complete the
entire project by its required completion time of 130
days, the project must start 8 days earlier than it is
estimated to start.
• Like the earliest start and earliest finish times, the latest
start and latest finish times are sometimes shown in a
separate schedule table
Schedule for Consumer Market Study Project,
Showing Latest Start and Finish Times
13
Total Slack, Defined
• The difference between the calculated earliest finish time of the very
last activity and the project‘s required completion time is the total
slack (TS), sometimes called float.
• If total slack is positive, it represents the maximum amount of time
that the activities on a particular path can be delayed without
jeopardizing completion of the project by its required completion
time.
• On the other hand, if total slack is negative, it represents the amount
of time that the activities on a particular path must be accelerated in
order to complete the project by its required completion time.
• Total Slack = LF – EF or Total Slack = LS – ES
14
Critical Path
• This longest path in the overall network diagram
is called the critical path.
• One way to determine which activities make up
the critical path is to find which ones have the
least slack.
• All the activities with this value are on the critical
path of activities.
• The values of total slack for the consumer
market study project are shown in Figure on next
slide
Schedule for Consumer Market Study Project,
Showing Total Slack Values
15
Critical Path
• The lowest value is –8 days.
• he activities that have this same value of total slack make up the
path 1–2–3–4–6–9–11–12–13.
• To eliminate the –8 days of slack, the estimated durations of one or
more activities on this critical path need to be reduced.
• Suppose we reduce the estimated duration of ―Mail Questionnaire &
Get Responses‖ from 65 days to 55 days. The total slack changes
from –8 days to +2 days.
• Those paths with positive values of total slack are sometimes
referred to as noncritical paths, while those paths with zero or
negative values of total slack are referred to as critical paths.
• n this case the longest path is often referred to as the most critical
path.
16
Free Slack
• Free slack is the amount of time a particular activity can
be delayed without delaying the earliest start time of its
immediately succeeding activities.
• It is the relative difference between the amounts of total
slack for activities entering into the same activity.
• It is always a positive value
• In the network diagram (Figure on Next slide), there are
three instances where a particular activity has more than
one activity entering into it:
– Activity 9, ―Mail Questionnaire & Get Responses,‖ has activities
5 and 6 entering into it.
– Activity 10, ―Test Software,‖ has activities 7 and 8 entering into it.
– Activity 11, ―Input Response Data,‖ has activities 9 and 10
entering into it.
17
Free Slack
16
Free Slack
• The values of total slack for activities 5 and 6 are 0 and –
8 days, respectively.
• The lesser of these two values is –8 days for activity 6.
• The free slack for activity 5 is the relative difference
between its total slack, 0, and –8. This relative
difference is 8 days: 0 – (–8) = 8 days.
Scheduling-PERT
20
PERT
Programme Evaluation and Review Technique
• PERT developed in 1956-58 by a research team to aid in the
planning and scheduling of the US Navy‘s Polaris Missile
Programme which involved over three thousand different
contracting organization.
• The objective of the team was to efficiently plan and produce the
Polaris missile system.
• Since 1958, PERT has proved to be useful for all jobs or
projects which have an element of uncertainty in the matter of
estimation of duration, as in the case with new types of projects
the like of which have never been taken up before
20
CPM- Critical Path Method
• CPM was developed jointly by E.I DuPont Company and
Remington Rand Univac Division.
• The aim behind its development was to have a better planning
in controlling the overhaul and maintenance of chemical plants.
PERT and CPM both are based on the network
representation of activities and their scheduling
that determines the most critical activities to be
controlled so as to meet the completion date of
the project
20
PERT
• Since PERT was developed in connection with an R&D work,
therefore it has to cope with the uncertainties which are
associated with R&D activities. In PERT, total project duration is
regarded as a random variable and therefore associated
probabilities are calculated so as to characterize it.
• It is an event-oriented network because in the analysis of
network emphasis is given on important stages of completion of
task rather than the activities required to be performed to reach
to a particular event or task
• A pert is normally used for projects involving activities of non-
repetitive nature in which time estimates are uncertain.
• It helps in pin pointing critical areas in a project so that necessary
adjustment can be made to meet the scheduled completion date
of the project.
20
Probability Considerations Activity Duration
Estimates
• Optimistic time: time to complete an activity if
everything goes perfectly well.
• Most likely time: time to complete an activity
under normal conditions.
• Pessimistic time: time to complete an activity
under adverse circumstances.
21 1
The Beta Probability Distribution
• When using three time estimates, it is assumed that
they follow a beta probability distribution.
• The expected duration and variance is calculated using the
following formula:

( )
p m o e
t t t t + + = 4
6
1
( )
2
2
6
1
(
¸
(

¸

÷ =
o p
t t o
21 1
Estimation of Project Completion Time
As we are expecting a variability in the activity duration, the total project
may not be completed exactly in time. Thus, it is necessary to calculate the
probability of actually meeting the scheduled time of the project as well as
activities
Probability of completing the project by scheduled time (t
s
) is given by
|
|
.
|

\
| ÷
s
e
e s
T T
Z ob
o
Pr

The standard normal variate is given by

e
e s
T T
Z
o
÷
=

Where
e
T = expected completion time of the Project
=
e
o number of standard deviations the scheduled time lies from the expected
(mean time)

Variance ( )
2
o of the critical path can be known by adding variances of the critical
activities
22
Example - PERT
A project is represented by the network shown below and has the following data
Task A B C D E F G H I
Optimistic 5 18 26 16 15 6 7 7 3
Pessimistic 10 22 40 20 25 12 12 9 5
Most likely 8 20 33 18 20 9 10 8 4

Determine the following
a) Expected task times and their variance
b) The earliest and latest expected times to reach each event
c) The critical path
d) The probability of an event occurring at the proposed completion date if the
original contract time of completing the project is 41.5 weeks



1
3
6
2
5
4
7
E
A
F I
H
B
C
D
G
Activity
o
t
p
t
m
t
( )
6
4
p m o
e
t t t
t
+ +
=
( )
2
0
2
6
(
¸
(

¸

÷
=
t t
p
o
1 - 2 5 10 8 7.8 0.696
1 - 3 18 22 20 20.0 0.444
1 - 4 26 40 33 33.0 5.429
2 – 5 16 20 18 18.0 0.443
2 – 6 15 25 20 20.0 2.780
3 – 6 6 12 9 9.0 1.000
4 – 7 7 12 10 9.8 0.694
5 – 7 7 9 8 8.0 0.111
6 - 7 3 5 4 4.0 0.111

Solution
Solution
E
1
=0
E
2
= E
1
+ T
1-2
= 0 + 7.8
E
3
= E
1
+ T
1-3
= 0 + 20.0 = 20.0
E
4
= E
1
+ T
1-4
= 0 + 33.0 = 33.0
E
5
= E
2
+ T
2-5
= 7.8 + 18.0 = 25.8
E
6
= max {E
i
+ t
i,6
} = max {E
2
+ t
2,6
; E
3
+ t
3,6
}
=max {7.8 + 20.0 ; 20 +9.0}= 29.0
E
7
= max {E
i
+ t
i,7
} = max {E
5
+ t
5,7
; E
6
+ t
6,7
; E
4
+ t
4,7
}
=max {25.8 + 8 ; 29 +4; 33+9.8}= 42.8
Earliest Start and Earliest Finish ( Forward Pass)

Expected Length of Critical Path = 8 . 42 =
e
t
Variance of Critical Path = 123 . 6 694 . 0 429 . 5 = +
It is given that
s
T =41.5, 8 . 42 =
e
T and 474 . 2 123 . 6 = =
e
o

Therefore, probability of meeting the schedule time is given by

|
|
.
|

\
| ÷
s
e
e s
T T
Z ob
o
Pr = Prob ( ) 52 . 0 ÷ s Z = 0.30 from normal distribution table
Thus, the probability that the project can be completed in less than
or equal to 41.5 weeks is 0.30. In other words, probability that
the project will get delayed beyond 41.5 weeks is 0.70

Schedule Control
2 2
Learning Objectives
- Perform the steps in the project control process
- Determine the effects of actual schedule performance
on the project schedule
- Incorporate project changes into the schedule
- Calculate an updated project schedule
- Control the project schedule
Project Control Process
The project control process involves :
– Regularly gathering data on project
performance,
– Comparing actual performance to planned
performance
– Taking corrective actions if actual
performance is behind planned performance

P
r
o
j
e
c
t

C
o
n
t
r
o
l

P
r
o
c
e
s
s

5
Project Control Process
• The key to effective project control is to measure actual progress
and compare it to planned progress on a timely and regular basis
and to take necessary corrective action immediately.
• Establish a regular reporting period.
• During each reporting period, collect:
– data on actual performance
– information on any changes to project scope, schedule and budget.
• If changes are incorporated, a new plan must be established.

Project management is a proactive approach to
controlling a project, to ensure that the project objective
is achieved even when things don't go according to plan
6
Effects of Actual Schedule Performance
• Throughout a project, some activities will be completed on time, some will be
finished ahead of schedule, and others will be finished later than the
schedule
• Actual Progress – whether faster or slower than planned – will have an effect
on the schedule of the remaining uncompleted activities of the project
• Actual finish times (AFT) of completed activities will determine the earliest
start and earliest finish times for the remaining activities.
7
Incorporating Project Changes into the Schedule
• Changes might be initiated by the customer or the
project team, or they might be the result of an
unanticipated occurrence.
• The degree of impact may depend on when the
changes are requested.
• If they‘re requested early in the project, they may have
less impact on cost and schedule
• When the customer requests a change, additional
costs might need to be charged.
Network Diagram for Consumer Market Study Project,
Showing the Critical Path
Revised Schedule for Consumer Market Study Project
8
Updating the Project Schedule
• Once data have been collected on the actual finish times
of completed activities and the effects of any project
changes, an updated project schedule can be calculated
based on the actual finish times of completed activities.
• Changes in the Network diagram studied in last class
– Completed Activities
Activity 1: ―Identify Target Consumers‖ actually finished on day 2
Activity 2: ―Develop Draft Questionnaire‖ actually finished on day 11
Activity 3 : ―Pilot-Test Questionnaire‖ actually finished on day 30
– Project Changes
• It was discovered that the database to be used to prepare the mailing labels
was not up to date. A new database needs to be purchased before the
mailing labels can be prepared. This new database was ordered on day 23.
It will take 21 days to get it from the supplier
• A preliminary review of comments from the pilot test of the questionnaire
indicates that substantial revisions to the questionnaire are required.
Therefore, the duration estimate for activity 4 needs to be increased from 5
days to 15 days

Network Diagram for Consumer Market Study Project,
Incorporating Actual Progress and Changes
Updated Schedule for Consumer Market Study Project
Consumer Market Study Project
9
Approaches to Schedule Control Four Steps
Schedule control involves four steps:
– Analyzing the schedule to determine which areas may need
corrective action
– Deciding what specific corrective actions should be taken
– Revising the plan to incorporate the chosen corrective actions
– Recalculating the schedule to evaluate the effects of the planned
corrective actions
• If the planned corrective actions do not result in an
acceptable schedule, these steps need to be repeated
10
Approaches to Schedule Control (Cont.)
• A change in the estimated duration of any
activity on that path will cause a corresponding
change in the slack for that path.
• When analyzing a path of activities that has
negative slack, you should focus on two kinds of
activities:
– Activities that are near term (that is, in progress or to
be started in the immediate future).
– Activities that have long estimated durations
11
Reducing the Estimated Durations
There are various approaches to reducing the estimated
durations of activities.
– One obvious way is to apply more resources to speed up an
activity. Sometimes, however, adding people to an activity may
in fact result in the activity‘s taking longer.
– Another approach is to assign a person with greater expertise or
more experience to perform or help with the activity.
– Reducing the scope or requirements for an activity is another
way to reduce its estimated duration.
– In an extreme case, it may be decided to totally eliminate some
activities.
– Increasing productivity through improved methods or technology
is yet another approach.
12
Approaches to Schedule Control (Cont.)
• In most cases, eliminating negative slack by reducing
durations of activities will involve a trade-off in the form
of an increase in costs or a reduction in scope.
• Some contracts include a bonus provision, whereby the
customer will pay the contractor a bonus if the project is
completed ahead of schedule.
• Conversely, some contracts include a penalty provision,
whereby the customer can reduce final payment to the
contractor if the project is not completed on time.
• The key to effective schedule control is to aggressively
address any paths with negative or deteriorating slack
values as soon as they are identified.
13
Schedule Control for Information Systems
Development
• Controlling the schedule for the development of an
information system is a challenge.
• Among the changes that commonly become necessary
during IS development projects are the following:
– Changes to input screens
– Changes to reports
– Changes to on-line queries
– Changes to database structures
– Changes to software processing routines
– Changes to processing speeds
– Changes to storage capacities
– Changes to business processes
– Changes to software resulting from hardware upgrades or,
conversely, hardware upgrades resulting from the availability of
more powerful software
14
Project Management Software
• The software allows you to perform various
control functions.
• The percent complete for each task can be
entered.
• Changes to the duration estimates can be
entered.
• The software will automatically revise the project
schedule and the corresponding network
diagrams.
Resource Considerations
2 2
Learning Objectives
• Learn how to take resource constraints into
account
• Determine the planned resource utilization for
a project
• Level the use of resources within the required
time frame
• Determine the shortest project schedule with
limited resources
Technically Constrained Activity Sequence
4
Resource-Constrained Planning
• Nearly all projects have limits on available
resources.
• Project delays often occur due to certain
resources being unavailable.
• A network diagram can be drawn to reflect the
availability of a limited number of resources.
Resource-Constrained Planning
5
Planned Resource Utilization
• If resources are to be considered in planning, it‘s
necessary to indicate the amounts and types of
resources needed to perform each activity.
Painting Project Showing Needed Resources
Planned Resource Utilization
Planned Resource Utilization
Resource Profile for Painters : Uneven Utilization of Painters
5
Planned Resource Utilization
• Sometimes it‘s preferable to have a more uniform, or
level, application of resources.
• Resource utilization based on each activity‘s earliest
start time are said to be based on an as-soon-as-
possible (ASAP) schedule.
• Resource utilization charts based on each activity‘s
latest start time are said to be based on an as-late-as-
possible (ALAP) schedule.
6
Resource Leveling
• Resource leveling, or smoothing, is a method for developing a
schedule that attempts to minimize the fluctuations in
requirements for resources.
• This method levels the resources so that they are applied as
uniformly as possible without extending the project schedule
beyond the required completion time.
• Non critical activities are delayed beyond their earliest start times
in order to maintain a uniform level of required resources
• Example : Utilization of Painters
Looking at Figure we can see that ―Bathroom‖ could be delayed up to 2 days,
―Basement Rooms‖ could be delayed up to 8 days, and ―Bedrooms‖ could be delayed
up to 6 days—all without extending the project completion time
6
Resource Leveling
Two alternative actions could be taken:
– Alternative 1. Delay the activity with the most
positive slack—―Basement Rooms‖ (+8 days
slack)—by 6 days so that it will start after
―Bedrooms‖ is finished.
– Alternative 2. Delay ―Bedrooms‖ so that it will
start on day 4, after ―Basement Rooms‖ is
completed.
Resource-Leveled Utillization
Resource-Leveled Profile for Painters
7
Resource-Limited Scheduling
• Resource-limited scheduling is a method for developing the
shortest schedule when the number or amount of available
resources is fixed and cannot be exceeded.
• This method will extend the project completion time if
necessary in order to keep within the resource limits.
• When several activities need the same limited resource at the
same time, the activities with the least slack have first priority
Effect of Limited Resource Availability
what would happen if only a limited number of painters—
two—were available to do the painting project.
Original Resource Utilization
Figure below shows that, as the project starts, three
activities require a total of four painters
Since ―First Floor Rooms‖ has a slack of 0 the two painters will be allocated to
the first floor rooms and will continue to be assigned to that activity until it is
finished
First Resource Allocation
This first resource allocation is shown in Figure below with
the project completion going from day 12 to day 14.
Second Resource Allocation
• The second resource allocation is shown in Figure below with the
project completion date going from day 14 to day 16.
Third Resource Allocation
• The third resource allocation is shown in Figure below with the
project completion date remaining at day 16
8
Project Management Software
• Provides excellent features for handling resource
considerations within a project.
• Allows you to create and maintain a list of resources.
• Resources can be assigned to various tasks within a
project.
• The user is informed if any resources have time
conflicts or if they are over-allocated.
• Numerous resource allocation reports can be
generated.
Software
Project
Planning
Objective
• To provide a framework that enables the
manager to make reasonable estimates of
resources, cost and schedule.
Task set for Project Planning
• Establish project scope
• Determine feasibility
• Analyze Risks
• Define required resources
• Estimate cost and effort
• Develop a project schedule
Various steps of planning activity
Size Estimation
Cost Estimation
Development Time
Resources
Requirements
Project
scheduling
Size Estimation
• The estimation of size is very critical and
difficult area of the project planning.
• It is difficult to establish the unit of
measurement.
Line of Code
• First measurement attempt.
• Advantage of being easily recognizable
and counted.
• Disagreement on what is included in line
of code.
• Early users of LOC did not include data
declarations, comments, or any other lines
that did not result in object code.
Line of Code (contd…)
• Conte has defined the lines of code as:
• ―A line of code is any line of program text
that is not a comment or blank line,
regardless of the number of statements or
fragments of statements on the line. This
specifically include all lines containing
program header, declarations and
executable and non executable
statements.‖
Disadvantage of using LOC
• It is language dependent
• They also reflect what the system is rather
than what it does.

• Measuring software size in terms of LOC
is analogous to measuring a car stereo by
the number of resistors, capacitors and
integrated circuits involved in it production.

Function Count
• Alan Albercht (IBM 1970) developed a
technique called Function Point Analysis.
• It measures functionality from users point of
view.
• It deals with functionality being delivered
Function Point Analysis
• The principle of Function Point Analysis is that a
system is decomposed into functional units
• The five function units are divided in two
categories:
• Data function types
– Internal Logical files
– External Interface files
• Transactional Function Types
– External Inputs
– External Outputs
– External Inquiry
internal
logical
files
external
inputs external
outputs
external inquiries
external interface files
Function Point Analysis
Special Features
• FPA is independent of the language, tools or
methodologies used for implementation
• Function points can be estimated from requirement
specification of design specifications, thus making it
possible to estimate development effort in early
phases of development.
• Function Points are directly linked to the statement
of requirements; any change of requirements can
easily be followed by a re-estimate
• They are based on the system user‘s external view
of the system
Counting Function Points
• The five functional units are ranked
according to their complexity i.e. Low,
Average or High.
• Organization that use FP methods develop
criteria for determining whether a
particular entry is Low, Average or High

Counting Function Points
Low Average High
Functional Units
Weighing Factors
External Inputs
External Output
External Inquiries
Internal Logical files
External Interface files
3 4 6
4 5 7
3 4 6
7 10 15
5 7 10
Functional Units Count complexity Complexity totals
Functional Unit
Totals
External Inputs

External Outputs

External Inquiries

Internal Logical
files


External Interface
Files


Low x 3
High x 6
Average x 4
=
=
=
Low x 4
High x 7
Average x 5
=
=
=
Low x 3
High x 6
Average x 4
=
=
=
Low x 7
High x 15
Average x 10
=
=
=
Low x 5
High x 10
Average x 7
=
=
=
Unadjusted Function Point
Procedure for Calculating UFP

ij
J
ij
I
w Z UFP
¿ ¿
= =
=
3
1
5
1


Where i indicates the row and j indicates the column of Table “Functional Units with
weighing factors

ij
w : It is the entry of the i
th
row and j
th
column of Table “Functional Units with weighing
factors


ij
Z : It is the count of the number of functional units of Type i that have been classified as
having the complexity corresponding to column j
Complexity adjustment Factor
• The final number of function points is arrived at
by multiplying the UFP by an adjustment factor
that is determined by considering 14 aspects of
processing complexity.
• This adjustment factor allows the UFP count to
be modified by at most ±35%.
• The final adjusted FP count is obtained by using
the following relationship
FP= UFP * CAF
Where CAF = 0.65 + x EFi
Complexity adjustment Factor
1. Does the system require reliable backup and recovery?
2. Is data communication required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing heavily utilized
operational environment?
6. Does the system require online data entry
7. Does the online data entry require the input to be built over
multiple screens or operations

Rate each factor on a scale of 0 to 5
0 1 2 3 4 5
No Influence Incidental Moderate Average Significant Essential
Complexity adjustment Factor
8. Are the master files updated online?
9. Is the inputs, outputs, files or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different
organizations?
14. Is the application designed to facilitate change and ease
of use by the user?

Rate each factor on a scale of 0 to 5
0 1 2 3 4 5
No Influence Incidental Moderate Average Significant Essential
Problem
• Consider a project with the following functional
units:
• no. of user inputs = 50
• No. of outputs = 40
• No. of user enquiries = 35
• No of user files = =06
• No of external interfaces = 04
• Assume all CAF and weighting factors are
average. Compute the FP for the project
Answer
ij
J
ij
I
w Z UFP
¿ ¿
= =
=
3
1
5
1


UFP = 50*4+40*5+35*4+6*10+4*7
=200+200+140+60+28=628

( )
¿
+ =
i
F CAF 01 . 0 65 . 0
=(0.65+0.01(14*3)) = 0.65 + 0.42 = 1.07

FP = UFP * CAF
=628 * 1.07 = 672
Problem
• An application has the following:
• 10 low external inputs, 12 high external outputs,
20 low internal logical files, 15 high external
interface files, 12 average external inquiries and
a value of CAF of 1.10.
• What are the unadjusted and adjusted FP
counts?
Answer
= 10*3 + 12*7 + 20*7 + 15*10 + 12*4
= 30 + 84 + 140 + 150 + 48 = 452
FP = UFP * CAF
= 452 * 1.10 = 497.2
ij
J
ij
I
w Z UFP
¿ ¿
= =
=
3
1
5
1
Example
Consider a project with the following parameters.
i) External Inputs
a) 10 with low complexity
b) 15 with average complexity
c) 17 with high complexity
ii) External outputs:
a) 6 with low complexity
b) 13 with high complexity
iii) External inquiries:
a) 3 with low complexity
b) 4 with average complexity
c) 2 with high complexity
Example
iv) Internal logical files:
a) 2 with average complexity
b) 1 with high complexity
v) External Interface files
a) 9 with low complexity
In addition to above system required
• Significant data communication
• Performance is very critical
• Designed code may be moderately reusable
• System is not designed for multiple installations in different
organizations.
Other complexity adjustment factors are treated as average.
Compute the function points for the project
The factor given in table may be calculated as

¿F
i
= 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41

CAF = (0.65 + 0.01 ׿F
i
)
= (0.65 × 0.01 × 41)
= 1.06
FP = UFP × CAF
= 424 × 1.06
= 449.44
i=1
14
Software
Project
Planning
Software Project Planning
The overall goal of project planning is to establish a
pragmatic strategy for controlling, tracking, and
monitoring a complex technical project.



Why?

So the end result gets done on time, with quality!
Project Planning Task Set-I
• Establish project scope
• Determine feasibility
• Analyze risks
• Define required resources
– Determine require human resources
– Define reusable software resources
– Identify environmental resources
Project Planning Task Set-II
• Estimate cost and effort
– Decompose the problem
– Develop two or more estimates using size,
function points, process tasks or use-cases
– Reconcile the estimates
• Develop a project schedule
– Scheduling Establish a meaningful task set
• Define a task network
• Use scheduling tools to develop a timeline chart
• Define schedule tracking mechanisms
Estimation
• Estimation of resources, cost, and
schedule for a software engineering effort
requires
– experience
– access to good historical information (metrics
– the courage to commit to quantitative predictions
when qualitative information is all that exists
• Estimation carries inherent risk and this
risk leads to uncertainty
Write it Down!
Software
Project
Plan
Project Scope
Estimates
Risks
Schedule
Control strategy
To Understand Scope ...
• Understand the customers needs
• understand the business context
• understand the project boundaries
• understand the customer‘s motivation
• understand the likely paths for change
• understand that ...
Even when you understand, nothing is guaranteed!
What is Scope?
• Software scope describes
– the functions and features that are to be delivered to end-users
– the data that are input and output
– the ―content‖ that is presented to users as a consequence of
using the software
– the performance, constraints, interfaces, and reliability that
bound the system.
• Scope is defined using one of two techniques:
• A narrative description of software scope is developed after
communication with all stakeholders.
• A set of use-cases is developed by end-users.
Resources
project
people
skills
number
location
reusable
software
OTS
components
f ull-experience
components
new
components
part.-experience
components
environment
hardware
software
tools
network
resources
Project Estimation
• Project scope must be understood
• Elaboration (decomposition) is
necessary
• Historical metrics are very helpful
• At least two different techniques
should be used
• Uncertainty is inherent in the
process
Estimation Techniques
• Past (similar) project experience
• Conventional estimation
techniques
– task breakdown and effort
estimates
– size (e.g., FP) estimates
• Empirical models
• Automated tools
Estimation Accuracy
• Predicated on …
– the degree to which the planner has properly
estimated the size of the product to be built
– the ability to translate the size estimate into human
effort, calendar time, and dollars (a function of the
availability of reliable software metrics from past
projects)
– the degree to which the project plan reflects the
abilities of the software team
– the stability of product requirements and the
environment that supports the software engineering
effort.
What makes a Successful Project?
Delivering:
agreed functionality
on time
at the agreed cost
with the required
quality

Stages:
1. set targets
2. Attempt to achieve
targets


Difficulties/Problems of estimation

• The uniqueness of project
• Changing technology
• Subjective nature of estimating
• Political implications (conflicting
interests of major stakeholders)
Cost Estimation

• Necessary to know the cost and
development time.
• Estimates are needed before development
is initiated.
• In many cases estimates are made using
past experience as the only guide.

Cost Estimation

A number of estimation techniques have
been developed and are having following
attributes in common:
• Project scope must be established in
advance.
• Software metrics are used as a basis from
which estimates are made.
• The project is broken into small pieces
which are estimated individually.
Cost Estimation

To achieve reliable cost and schedule estimates, a number
of options arise:
• Delay estimation until late in project.
• Use simple decomposition techniques to generate
project cost and schedule estimates.
• Develop empirical models for estimation.
• Acquire one or more automated estimation tools.
Unfortunately, the first option, however attractive, is not
practical. Cost estimates must be provided up front
Cost Estimation Models
• An Estimation model for computer software uses
empirically derived formulas to predict effort as a
function of LOC or FP.
• The empirical data that support most estimation
models are derived from limited sample of
projects.
• For this reason, no estimation model is
appropriate for all classes of software and in all
development environment.
Model
• The model is concerned with the representation
of the process to be estimated.
• A model may be static or dynamic.
• In static model, a unique variable is taken as a
key element for calculating all others.
• In dynamic model, all variables are
interdependent and there is no basic variable as
in static model
Model
• Single variable model: When a model makes
use of a single basic variable to calculate all
others it is said to be a single variable model.
• Multivariable model: In some models , several
variables are needed to describe the software
development process, and selected equations
combine these variables to give the estimate of
time and cost.
The variables, single or multiple that are input to the
model to predict the behaviour of a software development
are called predictors
The choice of handling of these predictors are most
crucial activity in estimating methodology
Static Single Variable Models
• Methods using this model use an equation to
estimate the desired values such as cost, time,
effort.
• Estimated values depend on same predictor (e.g.
size)
• Most common equation
C = aL
b
C is the cost (effort expressed in any unit of manpower, e.g.
man-months
L is the size, generally given in number of LOC
Constants a and b are derived from historical data of the
organization
(Since variables a and b depend on the local development
environment, these models are not transportable to different
organizations)
Static Single Variable Models
Software Engineering Laboratory of the
University of Maryland has established a
model, the SEL Model. This model is a typical
example of a Static Single-variable Model
E= 1.4 L
0.93
Doc = 30.4 L
0.90
D= 4.6 L
0.26

Effort (E in man-months), Documentation (DOC, in number of
pages) and duration (D in months) are calculated from the
number of LOC (L, in thousands of lines) used as a predictor
Static Multivariable Models
• These models are often based on equation of single
variable model (C = aL
b
).
• They depend on several variables representing various
aspects of the software development environment e.g
method used, user participation, customer oriented
changes, memory constraints etc..
• Walston and Felix Model (IBM 77) provides a
relationship between delivered lines of code (L in
thousands of lines) and effort E (E in person months)

E= 5.2L
0.91
D = 4.1 L
0.36

SEL Model
E = 1.4L
0.93
DOC = 30.4L
0.90
D = 4.6L
0.26
Where
E = Effort Person Months
DOC = Documentation in
number of pages and
D =duration in Months
L= number of lines of code (in
thousands of lines)
Static, Single Variable Models
Walston and Felix

E = 5.2L
0.91
D = 4.1L
0.36

L = (E/a)
1/b
L = (E/a)
1/b
Productivity
• Productivity is expressed as number of
lines of source code per person months
Example
• Compare the Walston-Felix model with SEL model on a
software development expected to involve 8 person
years effort
• Calculate the number of lines of source code that can be
produced
• Calculate the duration of the development
• Calculate the productivity in LOC/PY
• Calculate the average manning.
Solution
SEL
L = (96/1.4)
1/0.93
= 94264 LOC
D = 4.6(94.264)
0.26
= 15 months
P = 94264 / 8 = 11783
LOC/Person Years
M = 96 P-M / 15 M
= 6.4 Persons

W-F Model
L = (96/5.2)
1/0.91
= 24632 LOC
D = 4.1(24.632)
0.36
= 13 months
P = 24632/8 = 3079 LOC/Per
Person Years
M = 96 P-M / 13 M = 7.4 Persons
If we look at the value of “L” it seems that SEL can
produce four times as much software as W-F for the same
manpower and time scale
Discussion
• Since we cannot make absolutely
corrected estimation, should we on a side
of under- or over-estimation? Why?
Constructive Cost Model (COCOMO)
• Proposed by B.W. Bohem in his famous
book ―Software Engineering Economics‖ in
1981
• COCOMO is a hierarchy of software cost
estimation models, which include basic,
intermediate and detailed sub models
Basic Model
• Aims at estimating in a quick and rough
fashion.
• Used in small to medium size software
projects.
• Three modes of software development are
considered in this model: Organic, semi
detached and embedded
Basic Model
organic mode
– a small team of experienced developers develops
software in a very familiar environment.
– The size of the software development in this mode
ranges from small (a few KLOC) to medium (a few
tens of KLOC)
Embedded Mode
– The project has tight constraints, which might be
related to the target processor and its interface with
the associated hardware
– The problem to be solved is unique and so it is often
hard to find experienced persons, as the same does
not usually available
Semi detached mode
is an intermediate mode between the organic mode and
embedded mode.
Mode Project size Nature of Project Innovation Deadline
Development
Environment
Organic
Typically
2-50
KLOC
Small size project,
experienced
developers in the
familiar environment
Little Not tight
Familiar and
Inhouse
Semi
detached
Typically
50-300
KLOC
Medium size projects,
medium size team,
Average previous
experience on similar
projects
Medium Medium Medium
Embedded
Over 300
KLOC
Large Project, real
time systems, complex
interfaces, very little
previous experience
Significant Tight
Complex
Hardware/
interfaces
required

Comparison of three COCOMO Modes
Basic Model
• The basic COCOMO equations take the form



E is the effort applied in Person month
D is the development time in months
The coefficients a
b
,b
b
,c
b
,d
b
are given in table below
( )
b
b
b
KLOC a E =
( )
b
d
b
E c D=
Project a
b
b
b
c
b
d
b
Organic 2.4 1.05 2.5 0.38
Semi
detached
3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Basic COCOMO Coefficient
Basic Model
• When effort and development time are known,
the average staff size to complete the project
may be calculated as:
– Average staff size = E/D persons

• When project size is known, the productivity
level may be calculated as:
– Productivity P = KLOC/E KLOC/PM
• Example : Suppose that a project was estimated
to be 400 KLOC. Calculate the effort and
development time for each of the three modes
i.e. organic, semidetached and embedded.
Organic Mode
– E=2.4(400)
1.05
=1295.31 PM (Person-Month)
– D=2.5(1295.31)
0.38
=38.07 M
Semidetached Mode
– E=3.0(400)
1.12
=2462.79 PM (Person-Month)
– D=2.5(2462.79)
0.35
=38.45 M
Embedded Mode
– E=3.6(400)
1.20
=4772.81 PM (Person-Month)
– D=2.5(4772.81)
0.32
=38 M
Example
• Effort calculated for embedded mode is
approximately 4 times, the effort for organic mode
• Effort calculated for semidetached mode is 2
times the effort of organic mode.
• Surprisingly, the development time is
approximately the same for all three modes.
• Selection of Mode is very Important
– The selection of a mode is not only dependent on
project size, but also on other parameters as Nature of
Project, Innovation, Deadline of the project,
Development environment
Example
• A project size of 200 KLOC is to be
developed. Software development team
has average experience on similar type of
projects. The project schedule is not very
tight. Calculate the effort, development
time, average staff size and productivity of
the project.

Solution
• The semi detached model is the most
appropriate mode. Keeping in view the size,
schedule and experience of the development
team
E=3.0(200)
1.12
=1133.12 PM (Person-Month)
D=2.5(1133.12)
0.35
=29.3 M

Average Staff Size (SS) = Persons
D
E

= persons 67 . 38
3 . 29
12 . 1133
=

Productivity = PM KLOC
E
KLOC
/ 1765 . 0
12 . 1133
200
= =
= 176 LOC/PM
Intermediate Model
• The basic model allowed for a quick and rough
estimate, but it resulted in a lack of accuracy.
• Boehm introduced an additional set of 15
predictors called cost drivers in the intermediate
model to take account of the software
development.
• Cost drivers are used to adjust the nominal cost
of a project to the actual project environment,
increasing the accuracy of the estimate.
Intermediate Model
• The cost drivers are grouped into four categories
• Product attributes
– Requires software reliability (RELY)
– Database size (DATA)
– Product complexity (CPLX)
• Computer attributes
– Execution time constraint (TIME)
– Main storage constraint (STOR)
– Virtual machine volatility (VIRT)
– Computer turn around time (TURN)
Intermediate Model
• The cost drivers are grouped into four categories
• Personnel attributes
– Analyst capability (ACAP)
– Application experience (AEXP)
– Programmer capability (PCAP)
– Virtual machine experience (VEXP)
– Programming Language Experience (LEXP)
• Project attributes
– Modern programming practices (MODP)
– Use of software tool (TOOL)
– Required development schedule (SCED)
Intermediate Model
• Each cost drive is rated for a given project
environment.
• The rating uses a scale very low, low,
nominal, high, very high, extra high
Ratings
Cost drivers
Very low Low Nominal High Very High Extra High
Product Attributes
RELY 0.75 0.88 1.00 1.15 1.40
DATA 0.94 1.00 1.08 1.16
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
Computer Attributes
TIME 1.00 1.11 1.30 1.66
STOR 1.00 1.06 1.21 1.56
VIRT 0.87 1.00 1.15 1.30
TURN 0.87 1.00 1.07 1.15
Personnel Attributes
ACAP 1.46 1.19 1.00 0.86 0.71
AEXP 1.29 1.13 1.00 0.91 0.82
PCAP 1.42 1.17 1.00 0.86 0.70
VEXP 1.21 1.10 1.00 0.90
LEXP 1.14 1.07 1.00 0.95
Project attributes
MODP .124 1.10 1.00 0.91 0.82
TOOL 1.24 1.10 1.00 0.91 0.83
SCED 1.23 1.08 1.00 1.04 1.10

Intermediate Model
• The multiplying factors for all cost drivers
are multiplied to get the Effort Adjustment
Factor (EAF). Typically EAF range from
0.9 to 1.4
• The intermediate COCOMO equations
take the form:
( ) EAF KLOC a E
i
b
i
× =


( )
i
d
i
E c D =

Intermediate Model
Project a
i
b
i
c
i
d
i
Organic 3.2 1.05 2.5 0.38
Semi
detached
3.0 1.12 2.5 0.35
Embedde
d
2.8 1.20 2.5 0.32
Detailed COCOMO Model
• It offers a means for processing all the project
characteristics to construct a software estimate.
The detailed model introduces two more
capabilities:
• Phase-sensitive effort multipliers: some phases
(like design, programming, integration) are more
affected than others factors defined by cost
driers. The detailed model provides a set of
phase sensitive effort multipliers for each cost
drivers.
• Three–level product hierarchy: Three product
levels -module, subsystem and system are
defined. The ratings of the cost drivers are done
at appropriate level; that is the level at which it is
most susceptible to variation.
Development Phases
Software development is accomplished 4 successive
phases
• Plans/Requirements: In this phase full product
specification is generated and this consumes 6% to
8%of the effort and 10% to 40% of the development time
• Product design: requires 16% to 18% of the nominal
effort and can last up to 19% to 38% of the development
time
• Programming requires 48% to 68 % of the effort and
lasts from 24% to 64% of the development time
• Integration / Test: requires 16% to 34% of the nominal
effort and can last from 18% to 34% of the development
time.
Principle of effort estimate
• Size Equivalent:
– the software might be partly developed from software
already existing, a full development is not always
required. In such cases, the parts of Design
Document (DD%), Code (C%) and Integration (I%) to
be modified are estimated.
– Then an adjustment factor (A) is calculated by means
of the following equation.
A = 0.4 DD + 0.3 C +0.3 I 3.1
The size equivalent is obtained by
S (equivalent) = (S X A) /100
Where S represents the thousands of lines of code
(KLOC) of the module
Principle of effort estimate
• Multipliers have been developed that can be applied to
the total project effort, E, and the total project
development time, D in order to allocate effort and
schedule components to each phase in the life cycle
phases, and the effort and schedule for each phase are
assumed to be given in terms of the overall effort and
schedule by
• E
p
= µ
p
E
• D
p
= t
p
D
Mode & code size Plan and
Requirement
System
Design
Detail
Design
Module
code &
test
Integration
& test
Life Cycle Phase Value µ
p

Organic Small S = 2
0.06 0.16 0.26 0.42 0.16
Organic Medium S= 32
0.06 0.16 0.24 0.38 0.22
Semi det medium S= 32
0.07 0/17 0.25 0.33 0.25
Semi Det large S= 128
0.07 0.17 0.24 0.31 0.28
Embedded large S= 128
0.08 0.18 0.25 0.26 0.31
Embedded Extra. large
S= 320
0.08 0.18 0.24 0.24 0.34

Mode & code size Plan and
Requirement
System
Design
Detail
Design
Module
code &
test
Integration
& test
Lifecycle Phase Value of t
p

Organic Small S = 2
0.10 0.19 0.24 0.39 0.18
Organic Medium S =32
0.12 0.19 0.21 0.34 0.26
Semi det medium S= 32
0.20 0.26 0.21 0.27 0.26
Semi Det large S= 128
0.22 0.27 0.19 0.25 0.29
Embedded large S= 128
0.36 0.36 0.18 0.18 0.28
Embedded Extra large
S= 320
0.40 0.38 0.16 0.16 0.30

Principle of effort estimate
• COCOMO is highly calibrated model.
• It is easy to use and documented properly.
• It does not give proper importance to
software requirements and specification
phase.
Example
• A new project with estimated 400 KLOC embedded
system has to be developed. Project manager has a
choice of hiring from two pools of developers: very highly
capable with very little experience in the programming
language being used or developers of low quality but a
lot of experience with the programming language. What
is the impact of hiring developers from one or the other
pool.
Solution
• This is the case of embedded mode and model is
intermediate COCOMO.


E= 2.8 (400)
1.20
=3712 PM
• Case 1 Developers are very highly capable with very
little experience in the programming being used
EAF = 0.70 * 1.14
(Programmer Capability (PCAP) 0.70)
(Programming Language Exp (LEXP) 1.14
• E
1
= EAF *3712
• D = 2.5 (E
1
)
0.32



( )
i
b
i
KLOC a E =
( )
i
d
i
E c D =
Example
• Consider a project to develop a full screen
editor. The major components identified are (1)
Screen edit (2) Command Language Interpreter
(3) file input and output (4) cursor movement (5)
Screen Movement. The size of these are
estimated to be 4K, 2K, 1K, 2K and 3K delivered
source code lines. Use COCOMO model to
determine:
• (a) Overall cost and schedule estimates
• (b) Cost and schedule estimates for different
phases
Solution
• Size of five modules are:
• Screen edit = 4 KLOC
• Command Language Interpreter = 2
KLOC
• File input and output = 1 KLOC
• Cursor Movement = 2 KLOC
• Screen Movement = 3 KLOC
• Total =12 KLOC

Solution
Let us assume that the significant cost drivers are
– Required software reliability is high 1.15
– Product complexity is high 1.15
– Analyst capability is high 0.86
– Programming language experience is low 1.07
– All other drivers are nominal
EAF = 1.15 * 1.15 * 0.86 * 1.07 = 1.2169




( ) EAF KLOC a E
i
b
i
× =
( ) PM E 91 . 52 2169 . 1 2 . 1 2 . 3
05 . 1
= × =
( ) M D 29 . 11 91 . 52 5 . 2
38 . 0
= =
( )
i
d
i
E c D =
Using the following equations and referring phase wise cost and schedule estimates can
be calculated
E E
p p
× =µ
D D
p p
t =

Since size is only 12 KLOC, it is an organic small model. Phase wise effort distribution is
given below:

Effort Distribution
System Design 0.16 * 52.91 = 8.465 PM
Detailed Design 0.26 * 52.91 = 13.756 PM
Module Code and Test 0.42 * 52.91 = 22.222 PM
Integration and Test 0.16 * 52.91 = 8.465 PM
Time Distribution
System Design 0.19 * 11.29 = 2.145 M
Detailed Design 0.24 * 11.29 = 2.709 M
Module Code and Test 0.39 * 11.29 = 4.403 M
Integration and Test 0.18 * 11.29 = 2.032 M

Cost Planning and Performance
2 2 2
Learning Objectives (1)
• Items to consider when estimating cost
• Preparing a baseline budget
• Cumulating actual costs
• Determining the earned value of work
performed
• Analyzing cost performance
• Forecasting project cost at completion
• Controlling project costs
• Managing cash flow
4
Project Cost Estimates (2)
• Cost planning starts with the proposal for the project.
• The cost section of a proposal may consist of elements such as the
following:
– Labor. It might include the estimated hours and hourly rate for each
person or classification.
– Materials.
– Subcontractors and consultants (if used).
– Equipment and facilities rental. If the contractor needs special
equipment, tools, or facilities for the project.
– Travel. If it is required during the project.
• In addition to the above items, the contractor or project team may
include an amount for contingencies.
• It is good practice to have the person who will be responsible for
the costs associated with the work make the cost estimates.
• Historical data can be used as on the current project.
• Cost estimates should be realistic.
5
Project Budgeting (3)
The project budgeting process involves two steps.
• First, the project cost estimate is allocated to the
various work packages in the project work
breakdown structure.
• Second, the budget for each work package is
distributed over the duration of the work package..
6
Allocating the Total Budgeted Cost (TBC) (3A)
• Allocating total project costs for the various elements to
the appropriate work packages will establish a total
budgeted cost (TBC) for each work package.
• There are two approaches to establishing the TBC for
each work package: top-down and bottom-up
Work Breakdown Structure with Allocated Budgets (3A)
6
Allocating the Total Budgeted Cost (TBC) (3A)
• When the budgets for all the work packages are summed,
they cannot exceed the total project budgeted cost.
Network Diagram for the
Packaging Machine Project
Work Breakdown Structure
for the Packaging Machine
Project
7
Developing the Cumulative Budgeted Cost (3B)
• Once a total budgeted cost has been established
for each work package, the second step in the
project budgeting process is to distribute each
TBC over the duration of its work package.
• A cost is determined for each period, based on
when the activities that make up the work
package are scheduled to be performed.
• The cumulative budgeted cost (CBC) is the
amount that was budgeted to accomplish the
work that was scheduled to be performed up to
that point in time.
Budgeted Cost by Period for the Packaging Machine Project (3B)
Cumulative Budgeted Cost Curve for the Packaging Machine Project (3B)
7
Developing the Cumulative Budgeted Cost (3B)
• The CBC for the entire project or each work
package provides a baseline against which
actual cost and work performance can be
compared at any time during the project.
• It‘s important to use the cumulative
budgeted as the standard against which
actual cost is compared.
8
Determining Actual Cost (4)
• Once the project starts, it‘s necessary to keep track
of actual cost and committed cost so that they can
be compared to the CBC.

A. Actual Cost
• To keep track of actual cost on a project, it‘s
necessary to set up a system to collect, on a
regular and timely basis, data on funds actually
expended.
8
Determining Actual Cost (4B)
B. Committed Cost
• In many projects, large dollar amounts are expended
for materials or services (subcontractors, consultants)
that are used over a period of time longer than one cost
reporting period.
• These committed costs need to be treated in a special
way so that the system periodically assigns a portion
of their total cost to actual cost.
• Committed costs are also known as commitments or
encumbered costs.
• Costs are committed when an item is ordered even
though actual payment may take place at some later
time.
8
Determining Actual Cost (4C)
C. Comparing Actual Cost to Budgeted Cost
• As data are collected on actual cost, including portions of any committed
cost, they need to be totaled by work package so that they can be
compared to the cumulative budgeted cost.
• Cumulative actual cost (CAC) should be calculated.
Actual Cost by Period for the Packaging Machine Project
Figure indicates that at the end of week 8, $68,000 has actually
been expended on this project, although only $64,000 was
budgeted
Cumulative Budgeted and Actual Cost for the Packaging Machine Project (4C)
9
Determining the Value of Work Performed (5)
• Consider a project that involves painting ten similar
rooms over ten days (one room per day) for a total
budgeted cost of $2,000. The budget is $200 per room.
• At of the end of day 5, you determine that $1,000 has
actually been spent, but what if only three rooms have
been painted?
• Earned value, the value of the work actually performed,
is a key parameter that must be determined throughout
the project.
• Determining the earned value involves collecting data on
the percent complete for each work package and then
converting this percentage to a dollar amount by
multiplying the TBC of the work package by the percent
complete.
• In many cases, the estimate is subjective.
9
Determining the Value of Work Performed (5)
• It‘s important that the person estimating the
percent complete not only assess how much
work has been performed but also consider what
work remains to be done.
• For example, in the project involving painting ten
rooms for $2,000, if three rooms were
completed, it‘s safe to say that 30 percent of the
work has been performed.
• The earned value is 0.30 * $2,000 = $600
Calculate Cumulative Percent Complete by Period for the Packaging Machine Project (5)
Calculate Cumulative Earned Value by Period for the Packaging Machine Project (5)
Cumulative Budgeted, Actual, and Earned Value for the Packaging Machine Project (5)
10
Cost Performance Analysis Four Measures (6)
The following four cost-related measures are used to analyze project
cost performance:
- TBC (total budgeted cost)
- CBC (cumulative budgeted cost)
- CAC (cumulative actual cost)
- CEV (cumulative earned value)

• In the packaging machine project we see that:
– $64,000 was budgeted through the end of week 8.
– $68,000 was actually expended by the end of week 8.
– $54,000 was the earned value of work actually performed by
the end of week 8.
11 1
Cost Performance Analysis (6.1)
Cost Performance Index

• The cost performance index (CPI) is a measure of the cost efficiency
with which the project is being performed.
• The formula for determining the CPI is
Cost performance index =
F(Cumulative earned value, Cumulative actual cost)
OR CPI = F(CEV,CAC)

• In the packaging machine project, the CPI as of week 8 is given by :
CPI = F($54,000,$68,000) = 0.79

• This ratio indicates that for every $1.00 actually expended, only $0.79 of
earned value was received.
• When the CPI goes below 1.0 or gradually gets smaller, corrective
action should be taken.
11 1
Cost Performance Analysis (6.2)
Cost Variance
• Another indicator of cost performance is cost variance
(CV), which is the difference between the cumulative earned
value of the work performed and the cumulative actual cost.
• Cost variance =
Cumulative earned value – Cumulative actual cost
OR CV = CEV – CAC
• In the packaging machine project, the cost variance as of
week 8 is given by
• CV = $54,000 – $68,000 = –$14,000
• This calculation indicates that the value of the work
performed through week 8 is $14,000 less than the amount
actually expended.
13
Cost Forcasting Three Methods (7A)
Based on analysis of actual cost it’s possible to forecast what the
total costs will be at the completion of the project or work package.
• There are three different methods for determining the forecasted
cost at completion (FCAC).
• The first method assumes that the work to be performed on the
remaining portion of the project or work package will be done at the
same rate of efficiency as the work performed so far.
Forecasted Cost at Completion =
F(Total budgeted cost, Cost performance index)
• For the packaging machine project, the forecasted cost at
completion is given by:
FCAC = F($100,000,0.79) = $126,582
13
Cost Forcasting Three Methods (7 B)
• A second method for determining the forecasted cost at
completion assumes that, regardless of the efficiency rate
the project or work package has experienced in the past, the
work to be performed on the remaining portion of the project
or work package will be done according to budget.
• Forecasted cost at completion =
Cumulative actual cost+ (Total budgeted cost – Cumulative earned value)
• For the packaging machine project, the forecasted cost at
completion is given by:
FCAC = $68,000 + ($100,000 – $54,000)
= $68,000 + $46,000
= $114,000
13
Cost Forcasting Three Methods (7C)
• A third method for determining the forecasted cost
at completion is to re-estimate the costs for all the
remaining work to be performed and then add this
re-estimate to the cumulative actual cost.
• FCAC = CAC + Re-estimate of remaining work to
be performed
14
Cost Control (8 A)
• The key to effective cost control is to analyze cost
performance on a regular and timely basis.
• It‘s crucial that cost variances and inefficiencies be
identified early so that corrective action can be taken
before the situation gets worse.
• Cost control involves the following:
– Analyzing cost performance to determine which work packages
may require corrective action
– Deciding what specific corrective action should be taken
– Revising the project plan—including time and cost estimates—
to incorporate the planned corrective action
14
Cost Control (8 B)
• When evaluating work packages that have a
negative cost variance, you should
– focus on taking corrective actions to reduce the costs
of two types of activities:
• Activities that will be performed in the near term. If you put
off corrective actions until some point in the distant future,
the negative cost variance may deteriorate.
• Activities that have a large cost estimate. Taking corrective
measures that reduce the cost of a $20,000 activity by 10
percent will have a larger impact than totally eliminating a
$300 activity
14
Cost Control (8 C)
• There are various ways to reduce the costs of activities.
– One way is to substitute less expensive materials.
– Another approach is to assign a person with greater expertise or
more experience to perform or help with the activity.
– Reducing the scope or requirements is another way to reduce
costs.
– Increasing productivity through improved methods or technology.
• In many cases, there will be a tradeoff—reducing cost
variances will involve a reduction in project scope or a
delay in the project schedule.
• The key to effective cost control is aggressively
addressing negative cost variances and cost
inefficiencies as soon as they are identified.
17
Managing Cash Flow
• It is important to manage the cash flow on a project.
• Managing cash flow involves making sure that sufficient payments
are received from the customer in time so that you have enough
money to cover the costs of performing the project.
• The key to managing cash flow is to ensure that cash comes in
faster than it goes out.
• The contractor might try to negotiate payment terms that require
the customer to do one or more of the following:
– Provide a down payment at the start of the project.
– Make equal monthly payments based on the expected duration of the
project.
– Provide frequent payments, such as weekly or monthly payments
rather than quarterly payments.
• The worst scenario from the contractor‘s point of view is to have the
customer make only one payment at the end of the project.
18
Project Management Software
• All costs associated resources can be stored. The
software calculates the budget for each work
package and for the entire project.
• The software allows the user to define different
rate structures for each resource and when charges
for those resources will be accrued.
• Cost tables and graphs are available to help
analyze cost performance.
Risk Management
Projects can fail for a number of reasons and the risks
are always high. While a project manager cannot
eliminate risk, he/she can prevent or mitigate its
impacts by using risk management.

―If You Don’t Actively Attack the Risks,
The Risks Will Actively Attack You.‖
-Tom Gilb
Some definitions of risk
• Risk management is the process of identifying,
analyzing, controlling, and reporting risk.
• an uncertain even or condition that, if it occurs, has a
positive or negative effect

• The two characteristics of a risk in project management
are the following:
– It stems from the elements of uncertainty
– It might have negative or positive effects on meeting the project
objectives

Some definitions of risk
People may use different terms, but the key elements of a risk follow.

It relates to future:
Risk Planning involves speculating about future events. The future is
inherently uncertain. Some things which seem obvious when a
particular project is over, for example that the costs were under-
estimated or that a new technology was overly difficult to use, might
not have been so obvious during planning
It involves cause and effect
For example, a ‗cost over-run‘ might be identifies as a risk, but does
not say what caused it. Was it, for example, an inaccurate estimate
of effort, the use of untrained staff, or a poor specification?

A good definition of a specific risk identifies a situation (or hazard)
and a particular type of negative outcome.
Boehm’s top 10 development risks
Risk Risk reduction techniques
Personnel shortfalls Staffing with top talent; job matching;
teambuilding; training and career
development; early scheduling of key
personnel
Unrealistic time and
cost estimates
Multiple estimation techniques; design to
cost; incremental development; recording
and analysis of past projects;
standardization of methods
Developing the wrong
software functions
Improved software evaluation; formal
specification methods; user surveys;
prototyping; early user manuals
Developing the wrong
user interface
Prototyping; task analysis; user involvement
Boehm’s top ten risk - continued
Gold plating Requirements scrubbing, prototyping,
design to cost
Late changes to
requirements
Change control, incremental development
Shortfalls in externally
supplied components
Benchmarking, inspections, formal
specifications, contractual agreements, quality
controls
Shortfalls in externally
performed tasks
Quality assurance procedures, competitive
design etc
Real time performance
problems
Simulation, prototyping, tuning
Development
technically too difficult
Technical analysis, cost-benefit analysis,
prototyping , training
Categories of risk
Categories of risk
Actors : refers to all the people involved in the development of the application in
question. These include the various development specialists, the different
user group, and managers with differing responsibilities.
A typical risk in this area is that high staff turnover leads to information of
value to the project being lost. For example, if a software developer builds
a software component and then leaves before it has been fully tested, the
team member taking over the component might find that their lack of
familiarity with the software makes diagnosis and correction of faults
difficult.
Technology : Encompasses both the technology used to implement the
application and that embedded in the delivered products.
Risk here could relate to the appropriateness of the technologies and to
possible fault within them, especially if they are novel
Structure : describes the management structures and systems including those
affecting planning and control. For example, the implementation will need
the users to carry our some tasks, but the responsibility for managing the
users’ contribution to the project might not have been clearly allocated.
Tasks means the work to be carried out. For example the complexity of the
work might lead to delays because of the additional time required to co-
ordinate and integrate the large number of different elements.
Approaches to Risk Management
Approaches to Risk Management
Inactive Risk Management: We Simply neglect to consider risk issues at all. We
just do not bother to address, or even concern ourselves with, the possibility
that things may not turn out as we intend. – BAD Risk management Approach
Reactive Risk Management: We attempt to post-mortem efforts to ameliorate
the effects of risks that have materialized. This may involve crisis management
efforts to extricate an organization from a significant mess. More often, it is
concerned with getting rid of bad or defective products, often in the form of
inspections, before they are delivered to consumers. This involves scarp and
rework and therefore, increased production expenses.
Interactive Risk Management: We are concerned with risk throughout each of
the various lifecycles of various systems engineering efforts. This means that
we pay particular attention to such needs as configuration management and
project controls to ensure that each phase of each lifecycle is as risk free as
possible in terms of the risk associated with the product of that particular phase
Proactive Risk Management: We plan and forecast risk potentials and then
adopt systems management activities for technical directions that control, to the
extent possible, risk potentials across all organizational lifecycle processes.
Ideally, we manage risk in a manner such that it is very unlikely that any
unnecessary risk actually occurs. In this way, we avoid the scrap and rework
associated with an exclusively reactive approach to risk management.
General Lifecycle Approaches to Risk Management
Risk
Management
R
i
s
k

P
l
a
n
n
i
n
g

Formulation
Analysis
Interpretation
R
i
s
k

A
b
a
t
e
m
e
n
t

Detection
Diagnosis
Correction
Process of Risk Management
The process of risk management includes
– planning risk management : Used to determine
the how of the risk management – how to plan
and execute the risk management activities of
the given project
– Identifying and analyzing the risks :
– Preparing the response plan
– Monitoring the risk and
– Implementing the risk response, if the risk
occurs

Process Used in Risk Management
Risk
Management
Risk
Identification
Qualitative
Risk Analysis
Risk
Monitoring and
Control
Risk
Response
Planning
Quantitative
Risk Analysis
Planning Risk Management
Risk Management Planning is the process used to decide how the risk
management activities for the project at hand will be performed
The major goals for planning the risk management are threefold:
– Ensure that the type, level and visibility of Risk management are
proportionate with actual risk involved in the project and the importance
of the project to the organization
– Secure sufficient resources, including time for risk management
activities and
– Set up an agreed-upon basis for evaluating risks

To be specific, you use the risk management planning process to
determine the following:
– How to approach the risk management activities for this project
– How to plan the risk management activities
– How to execute the risk management activities


Risk identification
Risk Identification determines which risks might
affect the project and documents their
characteristics.
Participants in risk identification activities can
include the following, where appropriate:
– Project Manager
– Project Team Members
– Risk Management team (if assigned)
– Subject matter experts from outside the project team
– Customers, end users, other project managers, stakeholders
and risk management experts



Risk identification Tools and Techniques









Documentation Reviews:
• A structured review may be performed of project documentation, including
plans, assumptions, prior project files and other information.
• The quality of the plans, as well as consistency between those plans and
with the project requirements and assumptions can be indicators of risk in
the project
Information Gathering Techniques:
• Brainstorming
• Delphi Technique
• Interviewing
• Root Cause Identification
• Strengths, Weaknesses, Opportunities and threats (SWOT)
Analysis
Risk identification Techniques:
2. Information Gathering Technique : Brainstorming
• The goal here is to get a comprehensive list of potential
risks so that no risk goes unidentified.
• The project team, along with the relevant experts from
different disciplines, can participate in the brainstorming
session
• Brainstorming is better performed under the guidance of
a facilitator
• You can use the categories of risk to keep the session
focussed on the issue

Risk identification Techniques:
2. Information Gathering Technique : Delphi Technique
• The goal here is for experts to reach a consensus
without biases toward each other.
• The Delphi technique is used to ensure that it is the
quality of the information and the argument that are
important, not who is saying them.
• A facilitator circulates a questionnaire among the
experts to solicit ideas about the risks of the given
project.
• The experts respond anonymously.
• The responses are compiled and circulated among the
participating experts for further evaluation without
attaching a name to a response.
• It might take few iterations before a general consensus
is reached


Risk identification Techniques:
2. Information Gathering Technique : Interviewing
• This is one of the common methods used
for information-gathering for risk
identification.
• You interview the appropriate
stakeholders and subject matter experts
to gather information that will help identify
risks for the project at hand.


Risk identification Techniques:
2. Information Gathering Technique : Root Cause Identification
• A powerful way to identify risk is to look
for anything in the project that might
generate a risk.
• In other words, if you can spot a potential
cause for risks, it‘s simple to identify the
risks resulting from that cause.
• Furthermore, if you know the cause of a
risk, it helps to plan an effective response.
• You can also look for risks at the opposite
side of cause-that is impact.



Risk identification Techniques:
3. Information Gathering Technique : Checklist Analysis
• The carefully prepared a checklists in any
process are great no-brainer time savers
• The project in the same organisation will
more often than not have similarities
• As a result, you can develop a risk
identification checklist based on the
information gathered from a similar set of
projects previously performed.


Risk identification Techniques:
4. Information Gathering Technique : Assumption Analysis
• Assumptions in the project scope statement represent
uncertainties. You analyse these assumptions to identify
the risks
• Assumption analysis is the technique used to examine
the validity of the assumptions and thereby to identify
the risk resulting from the inaccuracies, inconsistencies
or incompleteness of each assumption.
• For example, assume that there is only one person in
the organization who has a rare skill needed for the
project. An obvious assumption would be that the
person will not quit the organization before completing
the assignment. The inaccuracy of this assumption
amounts to the risk



Risk identification Techniques:
5. Information Gathering Technique : Diagramming Techniques
These techniques use diagrams to identify risks by exposing and
exploring the risks‘ causes
Cause-and-effect Diagram : A cause-and-effect diagram illustrates
how various factors (causes) can be linked to potential problems
(effects)
Flowchart Diagram: A flowchart depicts how the elements of a system
are related to each other and shows the logical flow of a process.
By examining the flowchart of a process, the risk management
team can identify the points of potential problems in the flowchart
diagram.
Influence Diagram : An influence diagram is a graphical
representations of situations that shows relationships among
various variables and outcomes, such as casual influences and
time-ordering of events. By examining these diagrams, the risk
management team can recognize the potential problem areas and
thereby identify risks.


The Output of Risk identification
Risk Register
The Risk register is a document that
contains the output of the risk
identification process:
– List of identified Risks
– List of the root causes of the risks – This is a list of events or
conditions that might give rise to the identified risks
– Updated Risk Categories: Risks categories were originally
identified in the risk management planning process. However,
in the process of identifying risks new categories of risk may be
discovered or existing risk may be modified.
– List of potential risk Responses
The results of the risk identification process
usually lead to the qualitative risk.
• Depending upon the project and experience of the risk
management team, risk identification might lead directly to the
quantitative risk analysis and even to risk response planning
Analyzing Risk
After risks have been identified, You need to answer two
main questions for each identified risk:
– What are the odds that the risk will occur and
– If it does, what will its impact be on the project objectives?
You get the answer by performing risk analysis:
– Qualitative Risk Analysis
• This is used to prioritize risks by estimating the probability of their
occurrence and their impact on the project
– Quantitative Risk Analysis
• This is used to perform the numerical analysis to estimate the
effect of each identified risk on the overall project objectives and
deliverables
Analyzing Risk : Qualitative Risk Analysis
Prioritizing risks based on their probabilities of occurrence and their
impact if they do occur in the central goal of the qualitative risk
analysis.
Techniques used for Qualitative Risk Analysis involve estimating
probability and impact
• Risk Probability and Impact Assessment:
– Risk probability refers to the likelihood that a risk will occur, and
impact refers to the effect the risk will have on a project objective if it
occurs
– The probability for each risk and the impact of each risk on project
objectives, such as cost, quality, scope and time, must be assessed
– Methods include holding meetings, interviewing, considering expert
judgment and using an information base from previous projects
– A risk with a high probability might have a very low impact, and a risk
with a low probability might have a very high impact.

• To prioritize the risk, you need to look at both probability and impact
Analyzing Risk : Qualitative Risk Analysis
Probability and impact Matrix
– The prioritization can be performed by using the probability and
impact matrix – a lookup table that can be used to rate risk based on
where it falls both on the probability scale and on the impact scale
A Risk Probability and Impact Matrix for an Objective
Probability Impact
0.00 0.05 0.15 0.25 0.35 0.45 0.55 0.65 0.75 0.90
0.10 R
11
R
12
R
13
R
14
R
15
R
16
R
17
R
18
R
19

0.30 R
21
R
22
R
23
R
24
R
25
R
26
R
27
R
28
R
29

0.50 R
31
R
32
R
33
R
34
R
35
R
36
R
37
R
38
R
39

0.70 R
41
R
42
R
43
R
44
R
45
R
46
R
47
R
48
R
49

0.90 R
51
R
52
R
53
R
54
R
55
R
56
R
57
R
58
R
59


Risk R
45
has probability of 0.70 (that is, seven out of 10 chances) for
occurrence and an impact of 0.45 on the project objective for which
this matrix is prepared
How to calculate the numerical scales for the probability
and impact matrix and what they mean depends upon
the project and the organization
Remember
– Higher value of a risk on the probability scale means – Greater
likelihood of risk occurrence
– Higher value on the impact scale means- greater effect on the project
objectives
Analyzing Risk : Qualitative Risk Analysis
• Generally Risk Probability and impact matrix is divided into three
areas
– High Priority Risk
– Medium priority risks
– Low priority risk
Each organization has to design its own risk score and risk threshold
to guide the risk response plan
Note: Impact can be a threat (negative effect) or an opportunity ( a
positive effect) – Build separate matrices for threats and
opportunities
Threats on the high-priority area might require priority actions and
aggressive responses
You may have to capitalize on those opportunities in the high-priority
area, which you can do with relatively little effort
Risk posing threats in the low-priority area, might not need any
response, but they must be kept on the watch list

Analyzing Risk
Output of the Qualitative Risk Analysis
• Risk Categorization
• Prioritized list of risk
• List of risks with time urgency
• Watch list of low-priority list
• List of risk for additional analysis and response
• Trends in the analysis results

The main output of qualitative risk analysis is the
prioritization of risks based on a probability and impact
matrix for each objective
Analyzing Risk : Quantitative Analysis
Qualitative Risk Analysis is generally performed on the
risks that have been prioritized by using the qualitative risk
analysis.
Depending upon the experience of the team and their
familiarity with the risk, it is possible to skip the qualitative
risk analysis and move directly after the risk identification
to the quantitative risk analysis.
The quantitative risk analysis has three major goals:
– Assess the probabilities of achieving specific project objectives
– Quantify the effect of the risks on the overall project objectives
– Prioritize risks by their contributions to the overall project risk

Analyzing Risk : Quantitative Analysis Techniques
Interviewing : This technique is used to collect the data for assessing
the probabilities of achieving specific project objectives.
– You are looking for results such as: We have a 70% probability of
finishing the project within the schedule desired by the customer
– or perhaps we have a 60% probability of finishing the project within the
budget of $1,00,000.
• The goal is to determine the scale of probabilities for a given
objectives e.g. there is a 20% probability that the project will cost
$50,000, a 60% probability that it will cost $1,00,000, and a 20%
probability that it will cost $ 1,50,000
• The data is collected by interviewing relevant stakeholders and
subject matter experts . Most commonly, you will be exploring the
optimistic (best case), pessimistic (worst case) and most likely
scenarios for a given objective.
Analyzing Risk : Quantitative Analysis Techniques
Probability Distributions :
After you have collected the data on meeting the
project objectives, you can present it in a probability
distribution for each objective under study. Note that
distribution represents uncertainty, and uncertainty
represents risk.
For example, if you know for sure the project will cost
$25 million, there will be no distribution because it is
only one data point.
Distribution comes into the picture when you have
several possible values with a probability assigned to
each value.
Analyzing Risk : Quantitative Analysis Techniques
Sensitivity Analysis:
This is a technique used to determine which risk has the greatest
impact on the project.
You study the impact of one uncertain element on a project
objective by keeping all other uncertain elements fixed at their
baseline values.
You can repeat this analysis for several objectives, one at a time.
You can also repeat for several uncertain elements, one at a
time.
This way, you can see the impact of each element (or risk) on the
overall project separate from other elements.
Analyzing Risk : Quantitative Analysis Techniques
Expected Monetary value Analysis:
The expected monetary value (EMV) analysis is used to calculate the
expected value of an outcome when different possible scenarios
exist for different values of the outcome with some probabilities
assigned to them.
The goal here is to calculate the expected final result of a probabilistic
situation
• EMV is calculated by multiplying the value of each possible
outcome by the probability if its occurrence and adding the results.
– For example: If there is 60% probability that an opportunity will earn you $
1,000 and a 40% probability that it will only earn you $500, the EMV is
calculated as follows:
– EMV = 0.60*1000+0.40*500= 600+200 = 800
• When you are using the opportunities and threats in the same calculation,
take opportunity as positive value and for a threat as negative value
– For example, if there is a 60% chance that you will benefit from a risk by $1,000
and a 40% probability that you will lose $400 as a result of this risk, the EMV is
calculated as follows:
– EMV=0.60*1000-0.40*500 = 600-200=400

Analyzing Risk : Quantitative Analysis Techniques
Decision Tree Analysis:
• This technique uses the decision tree diagram to choose from different
available options, each option is represented by a branch of the tree
• This technique is used when there are multiple possible outcomes with
different threats or opportunities with certain probabilities assigned to them
• EMV analysis is done along each branch, which helps to make a decision
about which option to choose
Implementation
Successful
Update or Build
from scratch
Update
Cost=$50,000
Build from Scratch
Cost=$70,000
Implementation
Failed
Implementation
Successful
Implementation
Failed
Probability=40%
Probability=10%
Impact=$2,00,000
Loss of Revenue
Impact=$2,00,000
Loss of Revenue
Example of Decision Tree Diagram
Analyzing Risk : Quantitative Analysis Techniques
Option Initial
Cost
Risk Cost Probability EMV for Risk Total Cost
Update $ 50,000 $ 2,00,000 40% 0.40*$2,00,000
= $80,000
50,000+80,000
= $1,30,000
Build From
Scratch
$ 70,000 $ 2,00,000 10% 0.10*2,00,000
=$20,000
$70,000+$20,000
=$90,000

Though the initial cost for the update option is less than the initial cost for the
build-from-scratch option, the decision will be made in favor of the build-from-
scratch option because when you combine the initial cost with the EMV
resulting from the probability of failure, the build-from-scratch option turns out
to be a better deal
Analyzing Risk
Output Quantitative Analysis Techniques
Probabilistic analysis of the project:
– This includes the estimates of the project schedule and cost with a
confidence level attached to each estimate.
– Confidence level is expressed in percentage form such as 95% and it
represents how certain you are about the estimate
Probability of achieving the project objectives:
– Factoring in the project risks, you can estimate the probabilities
of meeting project objectives, such as cost and schedule set
forth by the current project plan. For example, the likelihood of
completing the project within the current budget plan of
$2million is 70%
Prioritized list of risks: Risks are prioritized according to the threats
they pose or the opportunities they offer.
Trends in the results: By repeating the analysis several times and by
examining the results, you might recognize a trend for specific risk.
That trend might suggest further analysis or a specific risk response
Risk prioritization
A common problem with risk identification, particularly for the more
anxious, is that a list of risks is potentially endless. Some way is,
therefore needed of distinguishing the more damaging and likely risks.
This can be done by estimating the RISK EXPOSURE for each risk
using the FORMULA
Risk exposure (RE) = (potential damage) x (probability of occurrence)

Ideally
Potential damage: a money value e.g. a flood would cause £0.5 millions
of damage
Probability 0.00 (absolutely no chance) to 1.00 (absolutely certain) e.g.
0.01 (one in hundred chance)

RE = £0.5m x 0.01 = £5,000
Crudely analogous to the amount needed for an insurance premium


Planning the Risk Response
Planning the Risk Response
Risk Response planning can start after risk identification,
qualitative risk analysis, or quantitative risk analysis.
Central task in risk response planning is to develop
actions and options to meet the following two goals
– Minimize threats to meeting project objectives
– Maximize opportunities
Three kinds of strategies available to handle three kinds of
scenarios:
– Strategies to respond to negative risks when actions is required
– Strategies to respond to positives risks when actions is required
– Strategies that can be used to respond to both negative and
positive risks when no action or a conditional action is taken
Planning the Risk Response: Response Strategies for Threats
Three strategies : Avoid, Transfer, Mitigate
• Avoid
– This can be accomplished in various ways, including
• Obtaining information and clarifying requirements for risks based on misunderstanding or
miscommunication. This answers two question: Do we really have this risk and if yes,
how can we avoid it?
• Acquiring expertise for risks that exist due to a lack of expertise
• Isolating the project objectives from the risk whenever possible
• Relaxing the objective that is under threat, such as extending the project schedule
• Transfer
– Risk transfer means you shift the responsibility for responding to the risk (the
ownership of the risk), the negative impact of the risk or both to another party.
Note that transferring the risk transfers the responsibility for risk management and
does not necessarily eliminate the risk.
– Risk transfer almost always involves making payment of a risk premium to the
party to which the risk has been transferred.

Planning the Risk Response: Response Strategies for Threats
Three strategies : Avoid, Transfer, Mitigate
• Mitigate
– Mitigation in general means taking action to reduce or prevent the impact
of a disaster that is expected to occur.
– Risk Mitigation means reducing the probability of risk occurrence,
reducing the impact of the risk if it does occur, or both
– A good mitigation strategy is to take actions early on to first reduce the
probability of the risk happening, and then to plan for reducing its impact
if it does occur, rather than letting it occur and they trying to reduce the
impact or repair the damage
• Following are some examples of mitigation:
– Adopting less complex process
– Conducting more tests on the product or service of the project
– Choosing a more stable supplier for the project supplies
– Designing redundancy into a system so that if one part fails, the
redundant part takes over and the system keeps working
Risk reduction leverage
Risk Reduction action can be assessed by calculating the Risk
Reduction Leverage. An RRL above 1.00 indicates that the
reduction in risk exposure achieved by a measure is greater
than its cost.
Risk reduction leverage = (RE
before
- RE
after
)/ (cost of risk reduction)

RE
before
is risk exposure before risk reduction e.g. 1% chance of a
fire causing £200k damage
RE
after
is risk exposure after risk reduction e.g. fire alarm costing
£500 reduces probability of fire damage to 0.5%
RRL = (1% of £200k)-(0.5% of £200k)/£500 = 2
RRL > 1.00 therefore worth doing

Planning the Risk Response: Response Strategies for Opportunities
Use ―SEE‖ approach to deal with the opportunities presented by the
positive risks
– Share
– Exploit
– Enhance
• Share: Sharing a positive risk that presents an opportunity means
transferring the ownership of the risk to another party that is better
equipped to capitalize on the opportunity.
• Exploit: Exploiting an opportunity means ensuring that the opportunity
is realized – that is, the positive risk that presents the opportunity does
occur. This is accomplished by eliminating or minimizing the
uncertainty associated with the risk occurrence. For example, Provide
better quality than planned to beat a competitor.
• Enhance: This strategy means increasing the size of the opportunity
by increasing the probability, impact or both. You can increase the
probability by maximizing the key drivers of the positive risks or by
strengthening the causes of the risks.
Planning the Risk Response:
Response Strategies for both Threats and Opportunities
There are two response strategies that you need to plan for the risks for
which you need to take either a conditional action or no action
Acceptance: Acceptance of a risk means to let it be. Generally, it is not
possible to take action against all the risks. Depending upon the
probabilities and impacts, some risks will simply be accepted: There
are two kinds of acceptance:
– Passive Acceptance that requires no action
– Active Acceptance that requires a condition action, called a contingent
response
• Contingency: Generally speaking, contingency means a future event
or condition that is possible but cannot be predicted with certainty. So,
your action will be contingent upon the condition- that is- it will be
executed only if the condition happens.
– In risk management a contingent response, is a response that is
executed only if certain predefined condition happens.
Output of the Risk Response Planning

1. Risk Register Updates : The appropriate risk responses planned and agreed
upon by the risk management team are included in the risk register. The
responses to high and moderate risks are entered in details, while the low-
priority risks can be put on a watch list for monitoring.
After the risk register is update, it included the following main elements:
– A list of identified risks, descriptions of the risks, root causes of the risks, WBS elements
affected by the risks, and the impacts of the risk on the project objectives
– Roles and responsibilities in managing the risks- that is, risk owners and the
responsibilities assigned to them
– Results from qualitative and quantitative risk analyses, including a prioritized list of risks,
probabilistic analysis of the project objectives and a list of risks with time urgency
– Planned and agreed-upon risk response strategies and specific actions to implement
each strategy
– Budget and Schedule requirements to implement the planned responses, including the
contingency reserve, which is the amount of funds, time or both needed in addition to the
estimates in order to meet the organization‘s and stakeholder‘ risk tolerances and thresholds
– Fallback plans in case the planned responses prove to be inadequate
2. Risk Related Contractual Agreements- might results from transferring the risks
3. Project management Plan Updates
Risk Response Control
• Risk response control involves executing
the risk management plan in order to
respond to risk events over the course of
the project.
• When changes occur, the basic cycle of
identify, quantify, and respond is repeated.
• It is important to understand that even the
most thorough and comprehensive
analysis cannot identify all risks and
probabilities correctly- control and iteration
are required.

Tools and Techniques for Risk Response
Control
– Workarounds. Workarounds are unplanned
responses to negative risk events. Workarounds are
unplanned only in the sense that the response was
not defined in advance of the risk event occurring.
– Additional risk response development. If
the risk event was not anticipated, or the effect is
greater than expected, the planned response may
not be adequate, and it will be necessary to repeat
the response development process and perhaps the
risk quantification process as well.

Output From Risk Response Control
Corrective action. Corrective action consists
primarily of performing the planned risk
response (e.g., implementing contingency
plans or workarounds).
Updates to risk management plan. As
anticipated risk events occur or fail to
occur, and as actual risk event effects are
evaluated, estimates of probabilities and
value, as well as other aspects of the risk
management plan, should be updated.

Monitoring and Controlling the Projects
Introduction
Executing a project means
– Executing the project work according to the project management
plan based on some baselines, such as a schedule baseline, a
scope baseline, and a cost baseline
• Monitoring : Watching the course
• Controlling : Taking action to either stay the course or change the
wrong course
• Monitoring includes
– measuring the project performance,
– collecting and distributing information about the project
performance and
– evaluating the performance information to see the trends.
• Continuous monitoring helps the project management
team identify the areas that need to be controlled closely
by, for example, taking corrective or preventive actions
Monitoring and Controlling
Some of the major tasks involved in monitoring and controlling the project are
actions:
• Monitoring project performance by measuring it against the project
management plan in terms of parameters such as cost, schedule and scope
• Monitoring the project by collecting information to support status reporting
progress measurement and predictions and then distributing this information
among the stakeholders
• Evaluating performance to determine whether it needs to be controlled by
taking corrective or preventive actions.
• Monitoring risks by tracking and analyzing the already identified project risks
and by identifying new risks.
• Controlling risk by managing the execution of risk response plans when the
risks occur
• Maintaining an accurate and timely information base regarding the project as
it progresses.
• Monitoring and controlling changes and monitoring the implementation of
approved changes

Monitoring and Controlling
A project is monitored and controlled using the monitor and control
project work process, which is a high-level process that is performed
by executing more specific processes, such as cost control, schedule
control and scope control
Monitoring and
Control Project Work
Integrated Change
Control
Cost
Control
Manage
Project
Plan
Quality
Control
Risk
Monitoring
and
Controlling
Schedule
Control
Scope
Control
Fig. : Some Processes in the Monitoring and Controlling Process Group
Integrated Change Control Process
The integrated change control process is used to manage changes to the
project from project initiation through project closure.
A project rarely runs exactly according to the project management plan, and
therefore changes will inevitably appear.
The changes request can come from:
– Evaluating the project performance to bring the project in line with the project
management plan or
– They can come from other sources, such as the stakeholders

• Regardless of where changes originate from, all changes need to be
managed (monitored and control) which includes:
– getting the changes rejected or approved,
– seeing the approved changes implemented and
– changing the affected plans accordingly

Integrated Change Control Process
Managing change includes the following:
– Identifying a change that has occurred and receiving a change request
– Getting the requested changes approved or rejected. Depending on the
project and the performing organization, the authority to determine whether
a change is eventually rejected or approved might lie with the project
manager, a customer, a sponsor, or a committee.
• Monitoring and controlling the flow of approved changes involves:
– Making sure they are implemented
– Maintaining the integrity of the project baseline (cost, schedule and scope)
by updating it to incorporate the approved changes
– Coordinating changes and their impact across the project and updating the
affected documentation. For example, an approved schedule change might
impact cost, quality risk and staffing.
• Controlling the Project Quality- e.g. Through defect repairs and
recommended corrective and preventive actions
• Making sure that only the approved changes are implemented


Integrated Change Control Process
Input Tools and Techniques Output
- Change request
- Recommended Items:
 Corrective Actions
 Preventive Actions
 Defect Repairs
- Project Management Plan
- Work Performance
Information

- Project Management
Methodology
- Project Management
Information Systems
- Expert Judgment
Approved and Rejected
Items:
 Change Request
 Defect Repairs
 Corrective Actions
and
 Preventive Actions
Validated Items:
 Defect Repairs
Updates
 Project
Management Plan
 Project Scope
Statement

Controlling Quality
Controlling quality involves monitoring specific results to
determine whether they comply with the planned quality
standards, which include project processes and product
goals and controlling the results by taking actions to
eliminate unsatisfactory performance
Controlling Quality involves:
– Monitor specific project results, such as cost performance and
schedule performance, to determine whether they comply with the
planned quality standards, which include project processes and
product goals
– Identify ways to eliminate the causes of unsatisfactory performance


Controlling Quality
Input Tools and Techniques Output
- Output of quality
planning:
 Quality Management
Plan
 Quality Metrics
 Quality Checklist
- Output of direct and
manage project execution
- Approved change request
- Organizational Process
Assets

- Seven basic tools of
quality:
 Flowcharts
 Scatter diagram
 histogram
 Pareto diagram
 control chart
 cause and effect
diagram

- Statistical Sampling
- Inspection
- Defect Repair Review
- Quality Control
Measurement
- Recommended Items:
 Corrective Actions
 Preventive Actions
 Defect Repairs and
 Change of request
- Validated Items:
 Deliverables and
defect repair
- Updates:
 Project management
plan
 Quality baseline
and
 Organizational
process assets


Seven Basic Tools of Quality
1.Flowchart : To anticipate what quality problems might be and where they
might occur
2. Run Charts : Run charts are used to perform trend analysis, which is
the science of predicting future performance based on past
results. In quality control, trend analysis can be used to predict
such things as the number of defects and the cost to repair
them.
3. Scatter Diagram: A scatter diagram is used to show the pattern of the
relationship between two variables – an independent variable
and another variable that depends on the independent variable.
The dependent variable is plotted corresponding to the
independent variable. For example, a variable representing a
cause can be the independent variable, and a variable
representing the effect can be a dependent variable. The closer
the data points are to a diagonal line, the stronger the
relationships is between the two variables.
4. Histogram: A histogram is a bar chart that shows a distribution of
variables. Each bar can represent an attribute, such as defects
due to a specific cause and its height can represent the
frequency of the attribute, such as number of defects. This tool
helps to identify and rate the causes of defects.
Seven Basic Tools of Quality
5. Pareto Diagram : A Pareto diagram is used to rank the importance of
each error (problem) based on the frequency of its occurrence
over time in the form of defects. A defect is an imperfection or
deficiency that keeps a component from meeting its
requirements or specifications. A defect is caused by an error
(problem) and can be repaired by fixing the error. An Error in a
product can give rise to multiple defects, and by fixing the error
you repair all the defects caused by that error

The Pareto diagram (80/20 Rule) lets you rank errors based on
the frequency of defects they cause. The advantages of a
Pareto diagram are:
– It ranks errors according to the frequency of defects they cause
– It optimizes efforts to repair the defects by working on the errors
that cause most of the defects
Seven Basic Tools of Quality
6. Control Charts :Control charts are used to monitor whether the variance of a
specified variable is within acceptable limits dictated by quality control.
A variance is a measurable deviation in the value of a project variable,
such as cost from a know baseline or expected value. This is a way to
monitor the deviations and determine whether the corresponding
variable is in or out of control. The values are taken at different times
to measure the behaviour of a variable over time.

The mean value in the control chart represents the expected value,
and predetermined spread from the mean value (usually ±3) is used to
define the limits within which an acceptable value can fall

Example : Assume that a manufacturer produces 100 units of a product each day
and it is expected that 95 out of 100 units should have no defect – that
is, the expected number of defective units is equal to 5. The control
limits are set to ±3. In other words, 95 units out of 100 must be correct,
give or take three. That puts the lower limit at 92 and the upper limit at
98. Crossing the lower limits is not acceptable to the customer and
crossing the upper litmus might require an unjustifiable cost.
An Example of a Control Chart
92
95
99
Lower control limit
Mean
Upper control limit
Time
Seven Basic Tools of Quality
7. Cause and Effect Diagram :A cause and effect diagram is used to explore all
the potential causes (inputs) that result in a single effect (output), such as a
problem or a defect. This type of diagram is the brainchild of Kaoru Ishikawa,
who pioneered quality management process in the Kawasaki Shipyards, and
therefore these diagrams are also called Ishikawa Diagrams. Due to the
shape of the diagram, it is also called as fishbone diagram. To construct and
use cause and effect diagrams effectively, perform the following simple steps:
a) Identify the Problem: Write down the problem in the box drawn on the right
side of a sheet of paper. This represents the head of the fish. Starting from
the box, draw a horizontal line across the paper. This represents the spine of
the fish
b) Identify the possible areas of causes: Identify the areas or factors from where
the potential causes of the problem might come. Environment, people,
materials, measurements and methods are some examples of areas (factors)
of causes. For each factor relevant to the problem under study, draw a line off
the spine and label it with the name of the factor. These lines represent the
fish bones.
c) Identify the possible causes: For ach factor, identify possible causes.
Represent each possible cause with a line coming off the bone that represent
the corresponding factor.
d) Analyze the diagram: Analyzing the diagram includes narrowing down the
most likely causes and investigating them further
An example of cause and effect diagram
Delay in Web Site
Release
Time
People
Shutdown
Periods
Efficiency of
Night Shifts
Hiring
Too many
Commitments
Shutdown
Periods
Methods
Environment
Need
Accuracy
Testing
Environment
Development
Environment
Efficiency
Cause and Effect Diagram :A cause and effect diagram is a structured way to
think through all possible causes of a problem. You can use these diagram to
carry out a thorough analysis of a problematic situation
Output of Quality Control
The quality control measurements and recommendations
based on those measurements are the obvious outputs
items of the quality control process.
Recommended Items:
– Recommended Corrective Actions
– Recommended Preventive Actions
– Recommended Defect Repair
– Request Changes
Validated Items
– Validated Defect Repair
– Validated Deliverables
Updates
Project management Plan
Quality Baseline
Understanding Project Closure
Understanding Project Closure
Project closure refers to a set of tasks that are required to formally end
the project. There are two kinds of projects that you need to close
formally:
Completed Projects : A project that has met its completion criteria falls
into this category
Terminated Projects: A project that was terminated before its
completion falls into this category. A project can be terminated at
various stages for various reasons. Following are some examples:
– The project management plan is not approved for whatever reason
– The project has been executing but you have run out of resources and
no more resources are available
– The project has been cancelled because it was going nowhere
– The project has been indefinitely postponed because there is not a large
enough market for the product it would produce
Understanding Project Closure
The process of closure consists of two kinds of tasks:
– Establish procedures to co-ordinate the activities needed to close the
project
– Implement the procedures
There are two aspects of closing a project:
Administrative closure:
– Performing administrative closure of a project includes obtaining final
acceptance for the project deliverables, analyzing the project‘s success
or failure, gathering lessons learned, archiving project information and
releasing project resources.
– How will these activities be performed and coordinated, any by whom?
For that, you establish an administrative closure procedure for your
project that will take into account the relevant policies and procedures of
the performing organization
Contract Closure
Contract closure includes settling and closing all the contracts associated
with the project. To carry out and co-ordinate the activities needed for
the contract closure, you define the contract closure procedure
Understanding Project Closure
Fig. The process to close
the project
Close
Project
Contract
Closure
1. Establish procedures for administrative
closure and contract closure
2. Implement Administrative Closure
1. Implement Contract Closure
Integrated Change Control Process
Input Tools and Techniques Output
- Project Management Plan
- Deliverables
- Work Performance
Information
- Contract Documentation
- Organizational Process
Assets
- Enterprise Environmental
Factors
- Project Management
Methodology
- Project Management
Information Systems
- Expert Judgment
 Administrative
closure procedure
 Formal Acceptance
for the final product
 Updates to
organizational
process assets
 Contract closure
procedrue

Output of the Project Closure
The output of the close project process contains
three kinds of elements
– Closing procedures
– Acceptance of the project deliverables by the
customer and
– Archival of project-related documents
Output of the Project Closure
Administrative Closure procedure:
– This procedure specifies the step-by-step methodology for the
administrative closure of the project, which includes specifying
all the necessary activities, roles and responsibilities of the
project team member who will participate in the closure process.
The activities defined by this procedure include the following:
• Activities to define the requirement for getting approval from the
stakeholders, such as customers and the sponsor on the project
deliverables and the approved changes which were supposed to be
implemented
• Activities that are necessary to satisfy the project completion or exit
criteria
• Activities related to the project completion, such as:
– Confirm that the project has met all requirements
– Verify that all deliverables have been provided and accepted
– Verify that the completion or exit criteria have been met
Output of the Project Closure
Formal Acceptance for the Final Product:
– This includes handing over the final product to
the customer and getting formal acceptance
for it – for example, in the form of a receipt
that contains statement to the effect that the
requirement of the project have been met,
including the terms or the contracts
Output of the Project Closure
Updates to Organizational process Assets:
– Acceptance Documentations
• This is the documentation that proves that the fulfillment of the project
requirement have been confirmed, completion of the project has been
verified and the product has been formally accepted by the customer.
– Project Closure Documentation
• In Additions to the acceptance documentation, you should also archive the
other project closure documents, such as the closure procedures and the
handing-over of project deliverables to an operation group. If the project was
terminated, then the formal documentation indicating why the project was
terminated should be included in the archive
– Project Files Archive
• This includes the documents from the projects‘ lifecycle such as the project
management plan, risk register, planned risk responses, and baselines for
cost, schedule, scope and quality
– Lessons-Learned database
• The documentation on lessons learned should be saved in the organizations
knowledge database so that future projects can benefit from it
– Contract Closure Procedure
• This procedure is developed to formally close all contracts associated with
the project. It specifies a step-by-step methodology to execute activities
needed to close the contract. The roles and responsibilities of the team
members who will be involved in the closure process are also specified.
Performing Contract Closure
A project might include work that was procured and that‘s where legal
agreements, such as contracts, come into the picture. The contracts are
closed at the end of a project or a phase by using the contract closure
process. Strictly speaking, the contract closure process is used to
accomplish the following two goals:
– Close all the contract applicable to the project
– Receive verification (if you are seller) or issue verification (if you are a
buyer) that all the procured deliverable were received and accepted. In
this respect, the contract closure process supports the administrative
closure of the project.
• If the project terminates without completion, you still need to go
through the contract closure process, if there is a contract. Usually a
contract contains the contract termination clause, which contains the
terms of the project termination, including the rights and
responsibilities of the parties in case of the; project‘s early
termination

Performing Contract Closure
Closing the contract means that procured work is
completed with all its requirement and is
accepted.
Generally, it is accomplished by a formal notice
from the buyer to the seller, which might come,
for example, through the buyer‘s authorized
administrator

The Finishing Touch – Reviewing the project
Part of the administrative closure is to analyze project success or
failure. You can accomplish this by collecting and generating the
project evaluation information, such as what went well and what did
not
Some of this information already exists in the work performance
reports. However, the final information can be gatheredin various
ways, such as a post-project review meetings with the team or a
questionnaire
The most important output of the review are the lessons learned.
The review should be comprehensive and should cover the following:
– Both the technical and non-technical components
– Both positive and negative aspects – that is, the things that went well
and the things that did not go well
– All stages and phases of the project
The Finishing Touch – Releasing the Resources
For the effective and efficient use of the organizational resources, it is
imperative that they be release in an efficient and proper manner.
The release procedure might be included in the resource planning – for
example, the staff management plan should address the issue of
releasing the human resources
Following are some suggestions to consider for properly releasing the
human resources:
– Although it is possible that different team members will be released at
different times, at the project closure you should organize some closure
events to honor and than the project team members, including the
contractors, for their contributions.
– Plan ahead, and do not wait until the last minute. Communicate with the
functional manager ahead of time about when a staff member is going
to be released
– Work closely with you organizations human resource department, which
might have some guidelines or procedure that you need to follow
– Write recommendation letters for team members who have mad the
outstanding contributions to the project
Solution Unit Test 1
Software Project Management
Q1a)
Why is it important to determine the critical
path of a project? What happens if activities
on this path are delayed? What happens if
activities on this path are accelerated?
• If any activity on the critical path is delayed, the
whole project will be delayed, so it is important
to know what the critical path is. If any of these
activities are accelerated, the project completion
date will also be accelerated.
Q1b)
Give examples of situations in which an
individual might develop a request for
proposal.
• There are many possible answers to this
question. Some examples might include
an RFP for a new in-ground pool, a new
deck, or a new house.
Q1c)
How do customers evaluate proposals? What factors
might they consider?
• Customers evaluate contractors‘ proposals in many
different ways.
– Some customers first look at the prices of the various proposals
and select, for example, only the three lowest-priced proposals
for further evaluation.
– Other customers initially screen out those proposals with prices
above their budget or those whose technical section doesn‘t
meet all the requirements stated in the RFP.
– Other customers, especially on large projects, create a proposal
review team that uses a scorecard to determine whether each
proposal meets all requirements in the RFP and to rate the
proposal against predefined evaluation criteria, such as price,
schedule, capabilities, and experience.
Q1d)
Define proposal, and describe the
purpose of a proposal.
• A proposal is a selling document and its
purpose is to convince the customer that
you understand what the customer wants
and that you are the best one for the job.
Q1e) Why should a project have a well-defined reporting period?
During each reporting period, what kinds of data need to be
collected?
• A regular reporting period should be established for comparing
actual progress with planned progress. This must be done on a
regular basis to ensure the project is progressing as expected.
Reporting may be daily, weekly, bi-weekly, or monthly, depending
on the complexity or overall duration of the project. If a project is
expected to have an overall duration of a month, the reporting period
might be as short as a day. On the other hand, if a project is
expected to run five years, the reporting period might be a month.
• During each reporting period two kinds of data or information need
to be collected:
1. Data on actual performance. This includes
• the actual time that activities were started and/or finished
• the actual costs expended and committed
2. Information on any changes to the project scope, schedule, and budget.
These changes could be initiated by the customer or the project team,
or they could be the result of an unanticipated occurrence such as a
natural disaster, a labor strike, or the resignation of a key project team
member.
Q2) Calculate the ES, EF, LS, and LF times and the slack for each
activity in the figure below and identify the critical path for the
project. Can the project be completed in 30 weeks?
Activity ED ES EF LS LF TS
1. Prob. Def. 2 0 2 -5 -3 -5
2. Sys. Analysis 5 2 7 -3 2 -5
3. Design I/O 3 7 10 6 9 -1
4. Design DB 15 7 22 2 17 -5
5. Develop Input 8 10 18 11 19 1
6. Develop Output 10 10 20 9 19 -1
7. Develop DB 2 22 24 17 19 -5
8. Test System 6 24 30 19 25 -5
9. Implement 5 30 35 25 30 -5

No, this project cannot be completed within 30 weeks. With the current
estimates, it will take 35 weeks. The most critical path is: 1-2-4-7-8-9.
Q2) Assume that “Systems Analysis” actually finished at 8 weeks,
“Design Input & Output” actually finished at 15 weeks, and
“Design Database” actually finished at 19 weeks. Recalculate
the expected project completion time. Which activities would
you focus on in order to get the project back on schedule?
Activity ED ES EF LS LF TS AF
1. Prob. Def. 2
2. Sys. Analysis 5 8
3. Design I/O 3 15
4. Design DB 15 19
5. Dev. Input 8 15 23 11 19 -4
6. Dev. Output 10 15 25 9 19 -6
7. Dev. DB 2 19 21 17 19 -2
8. Test System 6 25 31 19 25 -6
9. Implement 5 31 36 25 30 -6

The project has slipped even further. With the current estimates, it will take
36 weeks. Attention should be given to all activities since they all have
negative slack. However, the path 6-8-9 is the most critical
Quiz – Software Planning
________________ is the systematic
arrangement of tasks to accomplish an
objective.
– scheduling
– planning
– team building
– controlling
• ANSWER: B
• The plan becomes a benchmark against
which ______ progress can be
compared.
– actual
– planned
– future
– expected
• ANSWER: A
• By participating in ____________ of the
work, individuals will become committed
to accomplishing it.
– planning
– controlling
– discussing of
– timing
• ANSWER: A
• The _______ step in the planning
process is to define the project objective
– first
– second
– third
– fourth
• ANSWER: A
• The project __________ must be clear,
attainable, specific, and measurable.
– a. environment
– b. cycle
– c. objective
– d. work forms
• ANSWER: C
• For a project, the objective is usually
defined in terms of scope, _______, and
cost.
– a. plan
– b. schedule
– c. controls
– d. packages
• ANSWER: B
• The _____________ breaks a project down
into manageable pieces, or items, to help
ensure that all of the work elements needed to
complete the project work scope are identified.
– work package plan
– work budget plan
– work breakdown staff
– work breakdown structure
• ANSWER: D
• _________ Is a hierarchical tree of end
items that will be accomplished or
produced by the project team during the
project.
– work package plan
– work budget plan
– work breakdown staff
– work breakdown structure
• ANSWER: D
• A WBS subdivides the project into
smaller pieces called _____________.
– object codes
– task statements
– work items
– work loads
• ANSWER: C
• The lowest-level item of any one branch
is called a ___________.
– object item
– task statements
– work package
– work loads
• ANSWER: C
• The ___________________ is a method
used to display, in tabular format, the
individuals responsible for accomplishing
the work items in the WBS.
– responsibility matrix
– resource map
– responsibility web
– task structure
• ANSWER: A
• A _____________ is defined as a piece
of work that consumes time.
– action
– activity
– element
– work object
• ANSWER: B
• When all the detailed activities have been
defined for each of the work packages, the
next step is to graphically portray them in a
__________________ that shows the
appropriate sequence and interrelationships to
accomplish the overall project work scope.
– bubble diagram
– network ladder
– network diagram
– responsibility chart
• ANSWER: C
• The Gantt chart combines the two
functions of _____________________.
– planning and leveling
– scheduling and evaluating
– planning and scheduling
– scheduling and controlling
• ANSWER: C

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->