You are on page 1of 412

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 projects
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 customers satisfaction and whether the project met the
customers 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 customers
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 customers 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 customers
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 customers 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 contractors 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 contractors 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 contractors 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
customers 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 doesnt 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
contractors 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 sciencetwo 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 acceptancethey 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
individuals 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 1950s:
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 activitys 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 activitys predecessor event, and the event
at the end (head of the arrow) of the activity is known as
the activitys 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, its 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 projects
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 thats 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
Projects 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 activitys 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 projects 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 projects 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 projects
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 activitys
duration estimate from the activitys 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 projects 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 123469111213.
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 Navys 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 theyre 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 activitys 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, its
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 its preferable to have a more uniform, or
level, application of resources.
Resource utilization based on each activitys earliest
start time are said to be based on an as-soon-as-
possible (ASAP) schedule.
Resource utilization charts based on each activitys
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 daysall without extending the project completion time
6
Resource Leveling
Two alternative actions could be taken:
Alternative 1. Delay the activity with the most
positive slackBasement 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
twowere 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 users 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 customers 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.
Threelevel 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.
Its important to use the cumulative
budgeted as the standard against which
actual cost is compared.
8
Determining Actual Cost (4)
Once the project starts, its 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, its
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)
Its 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, its 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 its 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.
Its 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 planincluding 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 tradeoffreducing 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 contractors 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 Dont 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.
Boehms 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
Boehms 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, its 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 organizations 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 projects 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 thats 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; projects 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 buyers 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 doesnt
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 might also like