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

• Pankaj Jalote, “Software Project Management in Practice”, 2002, Pearson Education Asia.

• Software Project Management- A unified Approach, Walker Royce, Pearson Education

3. Robert T. Futrell, Donald F. Shafer, and Linda I.. Shafer, “Quality Software Project Management” 2002, Pearson Education Asia.

4. Ramesh Gopalaswamy, “Managing Global Software Projects”, 2003, Tata McGraw-Hill

 What is a project?

Some dictionary definitions:

“A specific plan or design”

“A planned undertaking”

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

Longmans dictionary

Key points above are planning and size of task

 What is a Project?

A project is a temporary endeavor undertaken to create a unique product, service or result

Project Characteristics

1. Temporary every project has a definite beginning and a definite end. The end is reached when the project’s objectives have been achieved or when it becomes clear that the

project objectives will not or cannot be met and the project is terminated

– Temporary does not necessarily mean short in duration; many projects last for several years. In every, case, however, the duration of a project is finite; projects are not ongoing efforts
 Project Characteristics contd..

2. A Project creates unique deliverables, which are products,

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

Uniqueness is an important characteristic of project deliverables

• The presence of repetitive elements does not change the fundamental
uniqueness of the project work.

3. Progressive Elaboration
• Developing in steps and continuing by increments
 Project Objectives

To have a successful software project, the project objectives should be clearly defined

S – specific, that is, concrete and well-defined

M – measurable, that is, satisfaction of the objective can be objectively judged

A – achievable, that is, it is within the power of the individual or group concerned to meet the target

R – relevant, the objective must relevant to the true purpose of the project

T – time constrained: there is defined point in time by which the objective should be achieved
 Projects vs Operational Work
Organizations perform work (task) to achieve a set of objectives.
Generally, work can be categorized as either projects or operations, although
the two sometimes overlap.

They share many of the following characteristics:

• Performed by people
• Constrained by limited resources
• Planned, executed, and controlled.

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

The objectives of projects and operations are fundamentally different.

The purpose of a project is to attain its objective and then terminate.

Conversely, the objective of an ongoing operation is to sustain the
business.

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

To Sum up

A task is more ‘project-like’ if it is:

• Non-routine

• Planned

• Aiming at a specific target

• Work carried out for a customer

• Involving several specialisms

• Made up of several different phases

• Constrained by time and resources

• Large and/or complex

 Are software projects really different from other projects?

Not really! …but…

• Invisibility

• Complexity

• Conformity

• Flexibility

make software more problematic to build than other engineered artefacts.

 What is management?

This involves the following activities:

• Planning – deciding what is to be done

• Organizing – making arrangements

• Staffing – selecting the right people for the job

• Directing – giving instructions

continued…
 What is management?
(continued)

• Monitoring – checking on progress

• Controlling – taking action to remedy hold-ups

• Innovating – coming up with solutions when problems emerge

• Representing – liaising with clients, users, developers and other stakeholders

 What is Project Management

Project management is the application of knowledge, skills, tools and

techniques to project activities to meet project requirements.

• Project management is accomplished through the application and

integration of the project management processes of initiating,
planning, executing, monitoring and controlling, and closing.

• The project manager is the person responsible for accomplishing the

project objectives

Managing a Project Includes:

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

Project Managers often talk of a “triple constraint”

• Project Scope
• Time and
• Cost

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

Project Managers also Manage projects in response to uncertainty

Project risk is an uncertain event or condition that, if it occurs, has a
positive or negative effect on at least one project objective

The Project Management team has a professional responsibility to its

stakeholders including customers, the performing organization and the
public
 Activities covered by project management

Feasibility study

Is project technically feasible and worthwhile from a business point of view?

Planning

Only done if project is feasible

Execution

Implement plan, but plan may be changed as we go along

Project Management
Knowledge Areas
 Project Management Knowledge Areas

Project Integration Management, describes the processes and activities that

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

Project Scope Management, describes the processes involved in ascertaining

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

Project Time Management, describes the processes concerning the timely

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

Project Cost Management, describes the processes involved in planning,

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

Project Quality Management, describes the processes involved in assuring that

the project will satisfy the objectives for which it was undertaken. It consists of
the Quality Planning, Perform Quality Assurance, and Perform Quality Control
project management processes.

Project Human Resource Management, describes the processes that organize

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

Project Communications Management, describes the processes concerning

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

Project Risk Management, describes the processes concerned with conducting

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

Project Procurement Management, describes the processes that purchase or

acquire products, services or results, as well as contract management
processes. It consists of the Plan Purchases and Acquisitions, Plan
Contracting, Request Seller Responses, Select Sellers, Contract
Administration, and Contract Closure project management processes.
 Areas of Expertise Needed by the Project Team

Application Area Knowledge, Standards and Regulations

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

Functional departments and supporting disciplines, such as legal,

production and inventory management, marketing, logistics, and
personnel

Technical elements, such as software development or

engineering, and sometimes a specific kind of engineering, such as
water and sanitation engineering or construction engineering

Management specializations, such as government contracting,

community development, and new product development

Industry groups, such as automotive, chemical, agriculture, and

financial services.
 Areas of Expertise Needed by the Project Team

•Understanding the Project Environment

Cultural and Social Environment
International and Political Environment
Physical Environment

•General Management Knowledge & Skills

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

• Projects are non-routine - thus uncertain

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

• Clear objectives are essential which can be objectively assessed

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

• Communicate, communicate, communicate!

Lecture 2
 Review Lecture 1

What is a Project?

A Project is an endeavor to accomplish a specific objective through a unique set of interrelated tasks and the effective utilization of resources.
 Review Lecture 1

What are the attributes of a Project?

• A project has a well defined objective

• A Project is carried out through a series of interdependent tasks

• A project utilizes various resources to carry out the tasks

• A project has a specific time frame

• A project may be a unique or one-time endeavor

• A project has a customer

• Project involves a degree of uncertainity

 Review Lecture 1

What are four factors that constrain the achievement of a project Objective ?
 Review Lecture 1 : What is Project Management

Project management is the application of knowledge, skills, tools and

techniques to project activities to meet project requirements.

• Project management is accomplished through the application and

integration of the project management processes of initiating,
planning, executing, monitoring and controlling, and closing.

• The project manager is the person responsible for accomplishing the

project objectives

Managing a Project Includes:

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

Phase 1 : Identification of Need

• Customer requesting proposals from individuals, a project team or organizations to address the identified need or solve the problem. The need and requirements are usually written up by the customer in a

document called a Request for Proposal (RFP)

• Through RFP, customer asks to submit proposals

• Not all situations involve a formal RFP

 Project Life Cycle

Phase 2 : Develop a Proposed Solution

Submission of proposal(s) to the customer by one or more individuals or organizations

After a customer evaluates the submissions and selects the winning proposal, the customer and the winning contractor negotiate and sign a contract (agreement)

Phase 3 : Implementation of Proposed Solution

• Detailed planning for the project

• Implementing the Plan the plan to accomplish the project objective

 Project Life Cycle

Phase 4 : Terminating the Project

When a project is completed, certain close-out activities need to be performed:

– Confirming that all deliverables have been provided to and accepted by the customer

– All payments have been collected

– Evaluating performance of the project in order to learn what could be improved if a similar project were to be carried out in the future

– Obtain feedback from the customer to determine the level of the customer’s satisfaction and whether the project met the customer’s expectations.

– Obtain the feedback from the project team in the form of recommendations for improving performance of projects in the future
 The Project Management Process

Project Management involves a process of first establishing a plan and then implementing that plan to accomplish the project objective.

The Planning effort includes the following steps:

– Clearly define the project objective

– Divide and subdivide the project scope into major “pieces” or work packages by preparing work breakdown structure (WBS)

– Define the specific activities that need to be performed for each work package in order to accomplish the project objective

– Graphically portray the activities in the form of a network diagram. This diagram shows the necessary sequence and interdependencies of
activities to achieve the project objectives.

– Make a time estimate for how long it will take to complete each activity.

– Make a cost estimate for each activity

– Calculate a project schedule and budget to determine whether the project can be completed within the required time, with the allotted funds and
with the available resources.
 Project Life Cycle

Phase 1 : Needs Identification

 Need Identification
Need identification is the initial phase of the project life cycle. The customer identifies a need, a problem or an opportunity for a better way of doing something and therefore sees some benefit to undertaking a project that will result in an improvement or

advantage over the existing condition

This phase encompasses :

Identifying needs and selecting projects

Developing a request for proposal

The proposal solicitation process

 Need Identification : Project Selection

Project Selection involves :

1. Evaluating various needs or opportunities

2. Deciding which of these should move forward as a project to be implemented

3. Benefits and consequences need to be considered and evaluated. They could be quantitative and qualitative, tangible and intangible

The Steps in project Selection are :

– Develop a set of criteria against which the opportunity will be evaluated

– List assumptions that will be used as the basis for each opportunity

– Gather data and information for each opportunity to help ensure an intelligent decision regarding project selection

• Preliminary Financial Estimates associated with each opportunity

• Gather information about each stakeholder

– Evaluate the opportunity against the criteria

 Need Identification : Request for Proposal

The purpose of preparing a request for proposal is to state, comprehensively and in details, what is required from the customer’s point of view, to address the identified need

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

realistic price
 Need Identification : Request for Proposal - 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.

1. The RFP must include the customer requirements which define specifications and attributes

2. The RFP should state what deliverable the customer expects the contractor or project team to provide

3. The RFP should list any customer-supplied items.

4. The RFP might state the approvals required by the customer

5. Some RFPs mention the type of contract the customer intends to use

6. An RFP might state the payment terms the customer intends to use

7. The RFP should state the required schedule for completion of the project

8. The RFP should provide instructions for the format and content of the contractor proposals

9. The RFP should indicate the due date by which the customer expects potential contractors to submit proposals
 Need Identification : Request for Proposal - Guidelines

11. An RFP may include the evaluation criteria. Criteria might include

1. The contractor’s experience with similar projects

2. Technical approach proposed by the contractor
3. The schedule. Will the contractor be able to meet or beat the required schedule?
4. The cost.
1. If the estimate is based on time and materials, are the costs reasonable?
2. Have any items be left out
3. Does it appear that the contractor has submitted a low cost estimate but will add costs after the project is under way, resulting in final costs
that are much higher than the original estimate?

11. In rare cases an RFP will indicate the funds the customer has available to spend on the; project.
 Need Identification : Soliciting Proposal
Once the RFP has been prepared, the customer solicits proposals by notifying potential contractors that the RFP is available.

One way for customers to do this is by identifying a selected group of contractors in advance and sending each of them a copy of the RFP

Another approach to soliciting potential contractor is for the customer to advertise in certain business newspapers that the RFP is available and give instructions on how interested

contractors can obtain a copy.

Proposed Solution
 Proposed Solution

Lecture Learning

• Proposal marketing strategies and the bid/no-bid decision

• The development of winning proposals

• The proposals preparation process and the elements that may be included in a proposal

• Pricing considerations

• The evaluation of proposals

• Types of contracts between the customer and the contractor

 Proposed Solution : Bid / No Bid Decision
Competition

– Which other contractors might also submit a proposal in response to the RFP?
– Do any of these contractors have a competitive advantage, because of either pre-RFP marketing efforts or their previous work for
or reputation with the customer?

Risk

Is there a risk that the project will be unsuccessful – technically or financially?

Mission

Is the proposed project consistent with the contractor’s business 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
 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.
 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
9
Emphasize the benefits to the customer
 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

10
 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

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

11
 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

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

The cost section usually consist of

• Labor :

– estimated costs of the various classifications of people who are expected to work on the project.

– It might include the estimate hours and hourly rate for each person or classification

– The estimates should be realistic

• Materials

• subcontractors and consultants

• equipment and facilities rental

• travel

• documentation

• Overhead

– Contractor will add a percentage to costs in items above to cover their normal overhead – the indirect costs of doing business, such as insurance, depreciation,
accounting, general management, marketing and human resources

• escalation

• contingency or management reserve

• fee or profit

13
 Pricing Considerations
Be careful not to overprice or underprice the proposed project

Consider:

• reliability of the cost estimates

– Does the total cost of the proposed project is complete and accurate?

– Costs should be based on a recent similar project or, in the case of materials cost estimates, on current price lists, catalogues or quotations.

• Risk

– If the project involves an endeavor that has not been undertaken before, such as R&D, it may be necessary to include a large amount or contingency or management reserve funds.

• value of the project to the contractor

• customer’s budget

– Pre-RFP marketing may help to know the customer budget

• Competition

14
 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

15
 Customer Evaluation of Proposals

• Some look at the prices and select only from the three lowest-priced proposals

• Some screen out prices above budget or whose technical section doesn’t meet all the requirements

• Some create a proposal review team that uses a scorecard

• May submit a best and final offer (BAFO)

16
 Customer Evaluation of Proposals (Cont.)

• Criteria that might be used in evaluating:

–compliance with SOW
–understanding of the problem or need
–soundness of the proposed approach
–contractor’s experience and past success
–experience of key individuals
–management capability
–realism of the schedule
–price – reasonableness, realism, and completeness

17
 Types of Contracts

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 (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
19
 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

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

21
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 Planning

Processes
of
Initiating Closing
Activity
Processes Processes

Phase Time Phase

Start Finish

Overlap of Process Groups in a Phase

 1. Initiating a process

• Initiation – Committing the organization to begin the next phase of the project
 2. Planning a Processes

• Planning is of major importance to a project because the project involves doing something which has not been done before.

• As a result, there are relatively more processes in this section. However, the number of processes does not mean that project management is primarily planning

• The amount of planning performed should be commensurate with the scope of the project and the usefulness of the information developed.

• The relationships among the project planning processes are shown in Figure on next slide

• These processes are subject to frequent iterations prior to completing the plan. For example, if the initial completion date is unacceptable, project resources, cost, or even scope may need

to be redefined.

• In addition, planning is not an exact science—two different teams could generate very different plans for the same project.
 2. Planning process : Core processes

• Some planning processes have clear dependencies that require them to be performed in essentially the same order on
most projects. For example, activities must be defined before they can be scheduled or costed. These core planning
processes may be iterated several times during any one phase of a project. They include:

• Scope Planning — developing a written scope statement as the basis for future project decisions.

• Scope Definition — subdividing the major project deliverables into smaller, more manageable components.

• Activity Definition - identifying the specific activities that must be performed to produce the various project deliverables

• Activity Sequencing —identifying and 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, ma-terials) 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 process-es 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 follow-ing 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

 Quality
Assurance

Quality
Assurance

Information Team
Distribution Development
Scope
Verification
Source
Solicitation Selection
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 bud-get 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 Overall
Reporting Change Control

Scope Schedule Cost

change Control
Control Control

Quality Risk
Response Control
Control
 Closing Processes

Contract Close-out —completion and settlement of the contract, including resolution of any open items.
Administrative Closure —generating, gathering, and disseminating information to formalize phase or project completion
 Customizing Process Interactions

• The processes identified and their interactions meet the test of general acceptance—they apply to most projects most of the time. However,
not all of the processes will be needed on all projects, and not all of the interactions will apply to all projects.

• For example: An organization that makes extensive use of contractors may explicitly describe where in the planning process each
procurement process occurs.

• The absence of a process does not mean that it should not be performed. The project management team should identify and manage all
the processes that are needed to ensure a successful project.

• Projects which are dependent on unique resources (commercial software development, biopharmaceuticals, etc.) may define roles and
responsibilities prior to scope definition since what can be done may be a function of who will be available to do it.

• Some process outputs may be predefined as constraints. For example, management may specify a target completion date rather than
allowing it to be determined by the planning process.
 Customizing Process Interactions

• Larger projects may need relatively more detail. For example, risk identification might be further subdivided to focus separately on identifying cost risks,
schedule risks, technical risks, and quality risks.

• On subprojects and smaller projects, relatively little effort will be spent on processes whose outputs have been defined at the project level (e.g., a subcontractor
may ignore risks explicitly assumed by the prime contractor) or on processes that provide only marginal utility (there may be no formal communications plan
on a four-person project).

• When there is a need to make a change, the change should be clearly identified, carefully evaluated, and actively managed
Planning
 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

2
 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

3
 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

2
level of the WBS at which control will be exercised.
 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

2
 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
6
accomplishing the work package
Work Breakdown Structure for Festival Project
 Responsibility Matrix

• Displays in tabular format the individuals responsible for accomplishing the work items in WBS.

• It is a useful tool because it emphasizes who is responsible for each work item and shows each individual’s role in supporting the overall project

• “X” can be used to indicate who is responsible.

• “P” indicates who has primary responsibility.

• “S” indicates who has secondary responsibility.

7
Responsibility Matrix for Festival Project
 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 2.Specify 3.Buy Material 4.Construct

Booths material Booths

5.Paint Booths 6.Dismantle 7.Move booths to 8.Dismantle

Booths festival site booths and
and move to
reassemble storage

8
 Developing the Network Plan

• After all activities have been defined, they are graphically portrayed in a network diagram that shows the appropriate sequence and interrelationships needed to

accomplish the overall project work scope.

• Two network planning techniques were developed in the 1950’s:

– Program evaluation and review technique (PERT)

– Critical path method (CPM)

• Network Diagram shows the sequential flow and interrelationships of activities.

9
 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

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

11
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 A ctivity on the node (AON)

– Activity on the arrow (AOA)

 Activity in the Box (AIB)
• Each activity is represented by a box.

• The activity description is written in the box.

Get
Volunteers
7

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

13
 AIB : Sequential and Concurrent Activities

Wash Car Dry Car

3 4

Dismantle
Get Booth
Volunteers 11
7
Construct Paint
Booth Booth
9 10
Buy
Materials
8
Clean Up
12
 Activity on the Arrow (AOA)
• Each activity is represented by an arrow.

• The activity description is written above the arrow.

Collect Data

• Each activity is represented by one and only one arrow

• The tail of the arrow designates the start of the activity.

• The head of the arrow designates the completion of the activity.

• The length and slope of the arrow are in no way indicative of the activity’s duration or importance

14
 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”

Wash Car Dry Car

1 2 3

The event at the beginning (tail of the arrow) of the activity

is known as the activity’s predecessor event, and the event
at the end (head of the arrow) of the activity is known as
the activity’s successor event

15
 Activity on the Arrow (AOA) (Cont.)

• All activities going into an event (circle) must be finished before any activities leading from that event can start.

Get Dismantle
Volunteers Booth
6 11

Construct Paint
Booth Booth
8 9 10

Clean Up
Buy
12
Materials
7
• 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
15
 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.

1 3

B
• 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

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.

A
1 3
B
2

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

A C
1 4
Incorrect

D
B 5
2
A C
1 3 5

B D
2 4 6
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 C
1 3

B D
2 4

16
 Loops
• Not allowed because it portrays a path of activities that perpetually repeats itself.

A C
1 3

D
4

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

18
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
 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?

19
 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

20
Work Breakdown Structure for Consumer Market Study Project
 Guidelines for Preparing the Network Diagram (contd…)

• It may be preferable to draw a summary-level network first and then expand it to a more detailed network.

– A summary network contains a small number of higher-level activities rather than a large number of detailed activities.
• The level of detail may be determined by certain obvious interface or transfer points :

– If there is a change in responsibility – that is, a different person or organization takes over responsibility for continuing the work – it should define
the end of one activity and the start of other activities

• For example, if one person is responsible for building an item and another person is responsible for packaging it, these should
be two separate activities.

20
 Guidelines for Preparing the Network Diagram (contd…)

• Activities should not be longer in estimated duration than the time intervals at which actual project progress will be reviewed and

compared to planed progress.

– For example, if the project is a three-year endeavor and the project team plans to review project progress monthly, then the
network should contain no activities with estimated durations greater than 30 days.

– If there are activities with longer estimated durations, they should be broken up into more detailed activities with durations of 30
days or less

• Finally, when the entire network diagram has been drawn, it’s necessary to assign a unique activity number to each activity

20
Example : Network Diagram for Consumer Market Study Project
 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
Start Finish

B E G

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.

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

22
 Steps of the SDLC

• Problem definition

• System analysis

• System design

• System development

• System testing

• System implementation

23
 Project Management Software
You are advised to prepare the following

• WBS

• Responsibility Matrix

• Gant Chart

• Network Diagram

24
Scheduling
 Learning Objectives
• Estimate the duration for each activity

• Establish the estimated start time and required completion time for the overall project

• Calculate the earliest times at which each activity can start and finish, based on the project’s estimated start time

• Calculate the latest times by which each activity must start and finish in order to complete the project by its required completion time

• Determine the amount of positive or negative slack

• Identify the critical (longest) path of activities

2
 Real World Example

US Census 2000 Project

• A US Census takes place every 10 years in the form of a questionnaire from the US Census Bureau. Census information helps the government in making policies regarding health,
education, transportation, community services etc.

• Census participation takes only a few minutes, but it takes years for the employees of the Census Bureau. Census 2000 was a 13-year project that’s total life cycle cost $65 billion

• Planning for data collection is important. 520 local census offices across the US verify and collect as many addresses as possible

• Project’s goal was 70% response rate to the 2000 Census. The Bureau implemented a plan to spread the word about the census and stress its importance. A non-response plan was also
established to reach those that failed to complete the census

• The 2000 Census was considered to be the most accurate population count in US history. For the first time, census data was made available on the Internet

4
 Activity Duration Estimates
– The first step in scheduling is to estimate how long each activity will take.
– The duration estimate is the total elapsed time for the work to be done PLUS any associated waiting time.
– The person responsible for performing the activity should help make the duration estimate. However, for large projects it may not be
practical to have each person provide activity duration estimates.

– An activity’s duration estimate must be based on the quantity of resources expected to be used on the activity.

6
Network Diagram for Consumer Market Study Project,
Showing Duration Estimates
 Project Start and Finish Times

• It is necessary to select an estimated start time and a required completion time for the overall project.

• The project’s required completion time is normally part of the project objective and stated in the contract.

• If a project must be completed in 130 working days, we define the project’s estimated start time as 0 and its required completion time is day 130.

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

8
 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

9
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
 Latest Start and Finish Times

• Latest finish time (LF) is the latest time by which a particular activity must be finished in order for the entire project to be completed by its

required completion time, calculated on the basis of the project’s required completion time and the duration estimates for succeeding

activities.

• Latest start time (LS) is the latest time by which a particular activity must be started in order for the entire project to be completed by its

required completion time, calculated by subtracting the activity’s duration estimate from the activity’s latest finish time:

• LS = LF – Duration Estimate

• The LF and LS times are determined by calculating backward through the network diagram.

• Rule 2: The latest finish time for a particular activity must be the same as or earlier than the earliest of all the latest start times of all the

activities emerging directly from that particular activity.

11
Latest Finish Times
Network Diagram for Consumer Market Study Project,
Showing Latest Start and Finish Times

12
 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
 Total Slack, Defined

• The difference between the calculated earliest finish time of the very last activity and the project’s required completion time is the total slack (TS),

sometimes called float.

• If total slack is positive, it represents the maximum amount of time that the activities on a particular path can be delayed without jeopardizing completion of

the project by its required completion time.

• On the other hand, if total slack is negative, it represents the amount of time that the activities on a particular path must be accelerated in order to complete

the project by its required completion time.

• Total Slack = LF – EF or Total Slack = LS – ES

13
 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

14
Schedule for Consumer Market Study Project,
Showing Total Slack Values
 Critical Path

• The lowest value is –8 days.

• The activities that have this same value of total slack make up the path 1–2–3–4–6–9–11–12–13.

• To eliminate the –8 days of slack, the estimated durations of one or more activities on this critical path need to be reduced.

• Suppose we reduce the estimated duration of “Mail Questionnaire & Get Responses” from 65 days to 55 days. The total slack changes

from –8 days to +2 days.

• Those paths with positive values of total slack are sometimes referred to as noncritical paths, while those paths with zero or negative

values of total slack are referred to as critical paths.

• n this case the longest path is often referred to as the most critical path.

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

16
Free Slack

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

16
Scheduling-PERT
 PERT
Programme Evaluation and Review Technique

• PERT developed in 1956-58 by a research team to aid in the planning and scheduling of the US Navy’s Polaris Missile Programme which involved

over three thousand different contracting organization.

• The objective of the team was to efficiently plan and produce the Polaris missile system.

• Since 1958, PERT has proved to be useful for all jobs or projects which have an element of uncertainty in the matter of estimation of duration, as

in the case with new types of projects the like of which have never been taken up before

20
 CPM- Critical Path Method

• CPM was developed jointly by E.I DuPont Company and Remington Rand Univac Division.

• The aim behind its development was to have a better planning in controlling the overhaul and maintenance of chemical plants.

PERT and CPM both are based on the network

representation of activities and their scheduling
that determines the most critical activities to be
controlled so as to meet the completion date of
the project

20
 PERT

• Since PERT was developed in connection with an R&D work, therefore it has to cope with the uncertainties which are associated with R&D

activities. In PERT, total project duration is regarded as a random variable and therefore associated probabilities are calculated so as to characterize

it.

• It is an event-oriented network because in the analysis of network emphasis is given on important stages of completion of task rather than the

activities required to be performed to reach to a particular event or task

• A pert is normally used for projects involving activities of non-repetitive nature in which time estimates are uncertain.

• It helps in pin pointing critical areas in a project so that necessary adjustment can be made to meet the scheduled completion date of the project.

20
 Probability Considerations Activity Duration
Estimates

• Optimistic time: time to complete an activity if everything goes perfectly well.

• Most likely time: time to complete an activity under normal conditions.

• Pessimistic time: time to complete an activity under adverse circumstances.

20
 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:

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

σ =  (t p − t o )
1 2 
6 
211
 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 ) is given by

s

The standard normal variate is given by

Where = expected completion time of the Project

number of standard deviations the scheduled time lies from the expected
(mean time)

Variance of the critical path can be known by adding variances of the critical
activities 211
 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

F 6 I
3 7

B
E H

A
1 2 D
G
5
C

22
4
Solution

Activity

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

E1=0
E2 = E1+ T1-2 = 0 + 7.8
E3 = E1+ T1-3 = 0 + 20.0 = 20.0
E4 = E1+ T1-4 = 0 + 33.0 = 33.0
E5 = E2+ T2-5 = 7.8 + 18.0 = 25.8
E6 = max {Ei + ti,6 } = max {E2 + t2,6 ; E3 + t3,6}
=max {7.8 + 20.0 ; 20 +9.0}= 29.0
E7 = max {Ei + ti,7 } = max {E5 + t5,7 ; E6 + t6,7 ; E4 + t4,7}
=max {25.8 + 8 ; 29 +4; 33+9.8}= 42.8
Earliest Start and Earliest Finish ( Forward Pass)

Expected Length of Critical Path =

Variance of Critical Path =
It is given that =41.5, and

Therefore, probability of meeting the schedule time is given by

= Prob = 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
 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

2
 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
ro
je
t
c
C
o
t
n
ro
l
P
ro
c
e
s
 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

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

6
 Incorporating Project Changes into the Schedule

• Changes might be initiated by the customer or the project team, or they might be the result of an unanticipated occurrence.

• The degree of impact may depend on when the changes are requested.

• If they’re requested early in the project, they may have less impact on cost and schedule

• When the customer requests a change, additional costs might need to be charged.

7
Network Diagram for Consumer Market Study Project,
Showing the Critical Path
Revised Schedule for Consumer Market Study Project
 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

8
Network Diagram for Consumer Market Study Project,
Incorporating Actual Progress and Changes
Updated Schedule for Consumer Market Study Project
Consumer Market Study Project
 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

9
 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

10
 Reducing the Estimated Durations

There are various approaches to reducing the estimated durations of activities.

– One obvious way is to apply more resources to speed up an activity. Sometimes, however, adding people to an activity may in fact result in the activity’s
taking longer.

– Another approach is to assign a person with greater expertise or more experience to perform or help with the activity.
– Reducing the scope or requirements for an activity is another way to reduce its estimated duration.
– In an extreme case, it may be decided to totally eliminate some activities.
– Increasing productivity through improved methods or technology is yet another approach.

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

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

14
Resource Considerations
 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

2
Technically Constrained Activity Sequence
 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.

4
Resource-Constrained Planning
 Planned Resource Utilization
• If resources are to be considered in planning, it’s necessary to indicate the amounts and types of resources needed to perform each activity.

Painting Project Showing Needed Resources

5
Planned Resource Utilization
 Planned Resource Utilization
Resource Profile for Painters : Uneven Utilization of Painters
 Planned Resource Utilization

• Sometimes it’s preferable to have a more uniform, or level, application of resources.

• Resource utilization based on each activity’s earliest start time are said to be based on an as-soon-as-possible (ASAP) schedule.

• Resource utilization charts based on each activity’s latest start time are said to be based on an as-late-as-possible (ALAP) schedule.

5
 Resource Leveling

• Resource leveling, or smoothing, is a method for developing a schedule that attempts to minimize the fluctuations in

requirements for resources.

• This method levels the resources so that they are applied as uniformly as possible without extending the project schedule

beyond the required completion time.

• Non critical activities are delayed beyond their earliest start times in order to maintain a uniform level of required resources

• Example : Utilization of Painters

Looking at Figure we can see that “Bathroom” could be delayed up to 2 days, “Basement Rooms” could be delayed up to 8

days, and “Bedrooms” could be delayed up to 6 days—all without extending the project completion time

6
 Resource Leveling

Two alternative actions could be taken:

– Alternative 1. Delay the activity with the most positive slack—“Basement Rooms” (+8 days slack)—by 6 days so that it will start
after “Bedrooms” is finished.

– Alternative 2. Delay “Bedrooms” so that it will start on day 4, after “Basement Rooms” is completed.

6
Resource-Leveled Utillization
Resource-Leveled Profile for Painters
 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

7
 Effect of Limited Resource Availability

what would happen if only a limited number of painters—

two—were available to do the painting project.
 Original Resource Utilization

Figure below shows that, as the project starts, three

activities require a total of four painters

Since “First Floor Rooms” has a slack of 0 the two painters will be allocated to
the first floor rooms and will continue to be assigned to that activity until it is
finished
 First Resource Allocation

This first resource allocation is shown in Figure below with the project completion going from day 12 to day 14.
 Second Resource Allocation

• The second resource allocation is shown in Figure below with the project completion date going from day 14 to day 16.
 Third Resource Allocation

• The third resource allocation is shown in Figure below with the project completion date remaining at day 16
 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.

8
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
 Function Point Analysis

external interface files

internal
external logical
inputs files external
outputs

external inquiries
 Special Features

• FPA is independent of the language, tools or methodologies used for implementation

• Function points can be estimated from requirement specification of design specifications, thus making it possible to estimate development effort in early phases of

development.

• Function Points are directly linked to the statement of requirements; any change of requirements can easily be followed by a re-estimate

• They are based on the system user’s external view of the system
 Counting Function Points

• The five functional units are ranked according to their complexity i.e. Low, Average or High.

• Organization that use FP methods develop criteria for determining whether a particular entry is Low, Average or High
 Counting Function Points

Functional Units Weighing Factors

Low Average High

External Inputs 3 4 6

External Output 4 5 7

External Inquiries 3 4 6

Internal Logical files 7 10 15

External Interface files 5 7 10

 Unadjusted Function Point

Functional Unit
Functional Units Count complexity Complexity totals
Totals

Low x 3 =
External Inputs Average x 4 =
High x 6 =

Low x 4 =

External Outputs Average x 5 =

High x 7 =

Low x 3 =

External Inquiries Average x 4 =

High x 6 =

Low x 7 =
Internal Logical Average x 10 =
files High x 15 =

Low x 5 =
External Interface Average x 7 =
Files =
High x 10
 Procedure for Calculating UFP

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

: It is the entry of the ith row and jth column of Table “Functional Units with weighing
factors

: 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 Σ Fi

 Complexity adjustment Factor

Rate each factor on a scale of 0 to 5

0 1 2 3 4 5
No Influence Incidental Moderate Average Significant Essential

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
 Complexity adjustment Factor

Rate each factor on a scale of 0 to 5

0 1 2 3 4 5
No Influence Incidental Moderate Average Significant Essential

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

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

=(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
5 3
UFP = ∑ ∑Z ij wij
I =1 J =1

= 10*3 + 12*7 + 20*7 + 15*10 + 12*4

= 30 + 84 + 140 + 150 + 48 = 452

FP = UFP * CAF

= 452 * 1.10 = 497.2

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

14
∑ F = 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41
i
i=1

CAF = (0.65 + 0.01 ×∑ F )

i
= (0.65 × 0.01 × 41)

= 1.06

FP = UFP × CAF

= 424 × 1.06

= 449.44
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!

Project Scope Softwar

Estimates e
Risks Project
Schedule Plan
Control strategy
 To Understand Scope ...

• Understand the customers needs

• understand the business context

• understand the project boundaries

• understand the customer’s motivation

• understand the likely paths for change

• understand that ...

Even when you understand, nothing is guaranteed!

 What is Scope?

• Software scope describes

– the functions and features that are to be delivered to end-users

– the data that are input and output

– the “content” that is presented to users as a consequence of using the software

– the performance, constraints, interfaces, and reliability that bound the system.

• Scope is defined using one of two techniques:

• A narrative description of software scope is developed after communication with all stakeholders.

• A set of use-cases is developed by end-users.

 Resources

number software
tools
skills hardware

people
environment network
location resources

project

reusable
OTS
software
new
components components

full-experience part.-experience
components components
 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: Stages:

agreed functionality 1. set targets

on time 2. Attempt to achieve targets

at the agreed cost

with the required quality

 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 = aLb
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 L0.93

Doc = 30.4 L0.90

D= 4.6 L0.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 = aLb).

• 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.2L0.91

D = 4.1 L0.36
 Static, Single Variable Models
SEL Model Walston and Felix
E = 1.4L0.93

DOC = 30.4L0.90 E = 5.2L0.91

D = 4.6L0.26 D = 4.1L0.36
Where

E = Effort Person Months DOC = Documentation in number of pages and

D =duration in Months L = (E/a)1/b

L= number of lines of code (in thousands of lines)

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 W-F Model

L = (96/1.4)1/0.93 = 94264 LOC L = (96/5.2)1/0.91 = 24632 LOC

D = 4.6(94.264)0.26 = 15 months D = 4.1(24.632)0.36 = 13 months

P = 94264 / 8 = 11783 LOC/Person Years P = 24632/8 = 3079 LOC/Per Person Years

M = 96 P-M / 15 M M = 96 P-M / 13 M = 7.4 Persons

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

 Comparison of three COCOMO Modes

Development
Mode Project size Nature of Project Innovation Deadline
Environment

Small size project,

Typically
experienced Familiar and
Organic 2-50 Little Not tight
developers in the Inhouse
KLOC
familiar environment

Medium size projects,

Typically medium size team,
Semi
50-300 Average previous Medium Medium Medium
detached
KLOC experience on similar
projects
Large Project, real Complex
Over 300 time systems, complex Hardware/
Embedded Significant Tight
KLOC interfaces, very little interfaces
previous experience required
 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 ,c ,d are given in table below

b b b b

Project ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi 3.0 1.12 2.5 0.35
detached

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

=

Productivity =
= 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:

 Intermediate Model

Project ai bi ci di
Organic 3.2 1.05 2.5 0.38

Semi 3.0 1.12 2.5 0.35

detached

Embedde 2.8 1.20 2.5 0.32

d
 Detailed COCOMO Model

• It offers a means for processing all the project characteristics to construct a software estimate.

The detailed model introduces two more capabilities:

• Phase-sensitive effort multipliers: some phases (like design, programming, integration) are more affected than others factors defined by cost driers. The
detailed model provides a set of phase sensitive effort multipliers for each cost drivers.

• Three–level product hierarchy: Three product levels -module, subsystem and system are defined. The ratings of the cost drivers are done at appropriate
level; that is the level at which it is most susceptible to variation.
 Development Phases

Software development is accomplished 4 successive phases

• Plans/Requirements: In this phase full product specification is generated and this consumes 6% to 8%of the effort and 10% to 40% of the development time

• Product design: requires 16% to 18% of the nominal effort and can last up to 19% to 38% of the development time

• Programming requires 48% to 68 % of the effort and lasts from 24% to 64% of the development time

• Integration / Test: requires 16% to 34% of the nominal effort and can last from 18% to 34% of the development time.
 Principle of effort estimate
• Size Equivalent:

– the software might be partly developed from software already existing, a full development is not always required. In such cases, the parts of Design Document (DD%), Code (C
%) and Integration (I%) to be modified are estimated.

– Then an adjustment factor (A) is calculated by means of the following equation.

A = 0.4 DD + 0.3 C +0.3 I 3.1

The size equivalent is obtained by

S (equivalent) = (S X A) /100

Where S represents the thousands of lines of code (KLOC) of the module

 Principle of effort estimate
• Multipliers have been developed that can be applied to the total project effort, E, and the total project development time, D in order to allocate effort and schedule components to
each phase in the life cycle phases, and the effort and schedule for each phase are assumed to be given in terms of the overall effort and schedule by

E =µ E
• p p
D =τ D
• p p
Mode & code size Plan and System Detail Module Integration
Requirement Design Design code & & test
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 0.08 0.18 0.24 0.24 0.34
S= 320
Mode & code size Plan and System Detail Module Integration
Requirement Design Design code & & test
test

Lifecycle Phase Value of τ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 0.40 0.38 0.16 0.16 0.30

S= 320
 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.

D = ci ( E )
di

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 = EAF *3712
1

• D = 2.5 (E ) 0.32
1
 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

– E = ai ( KLOC ) i × EAF
All other drivers are nominal b

EAF = 1.15 * 1.15 * 0.86 * 1.07 = 1.2169

D = ci ( E )
di

E = 3.2(1.2 )
1.05
× 1.2169 = 52.91 PM

D = 2.5( 52.91)
0.38
= 11.29 M
Using the following equations and referring phase wise cost and schedule estimates can
be calculated

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

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

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

5
 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

6
Work Breakdown Structure with Allocated Budgets (3A)
 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.

Work Breakdown Structure

for the Packaging Machine
Project
Network Diagram for the
Packaging Machine Project 6
 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.

7
Budgeted Cost by Period for the Packaging Machine Project (3B)
Cumulative Budgeted Cost Curve for the Packaging Machine Project (3B)
 Developing the Cumulative Budgeted Cost (3B)

• The CBC for the entire project or each work package provides a baseline against which actual cost and work performance can be compared at any time during

the project.

• It’s important to use the cumulative budgeted as the standard against which actual cost is compared.

7
 Determining Actual Cost (4)

• Once the project starts, it’s necessary to keep track of actual cost and committed cost so that they can be compared to the CBC.

A. Actual Cost

• To keep track of actual cost on a project, it’s necessary to set up a system to collect, on a regular and timely basis, data on funds actually expended.

8
B. Committed Cost Determining Actual Cost (4B)
• 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
8
budgeted
Cumulative Budgeted and Actual Cost for the Packaging Machine Project (4C)
• 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.
Determining the Value of Work Performed (5)
• At of the end of day 5, you determine that $1,000 has actually been spent, but what if only three rooms have been painted?

• Earned value, the value of the work actually performed, is a key parameter that must be determined throughout the project.

• Determining the earned value involves collecting data on the percent complete for each work package and then converting this percentage to a dollar amount by multiplying the TBC
of the work package by the percent complete.

• In many cases, the estimate is subjective.

9
 Determining the Value of Work Performed (5)

• It’s important that the person estimating the percent complete not only assess how much work has been performed but also consider what work remains to be

done.

• For example, in the project involving painting ten rooms for $2,000, if three rooms were completed, it’s safe to say that 30 percent of the work has been

performed.

• The earned value is 0.30 * $2,000 = $600

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

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

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

111
 Cost Forcasting Three Methods (7A)
Based on analysis of actual cost it’s possible to forecast what the total costs will be at the completion of the project or work package.

• There are three different methods for determining the forecasted cost at completion (FCAC).

• The first method assumes that the work to be performed on the remaining portion of the project or work package will be done at the same rate of efficiency as the work performed so far.

Forecasted Cost at Completion =

F(Total budgeted cost, Cost performance index)

• For the packaging machine project, the forecasted cost at completion is given by:

FCAC = F($100,000,0.79) = $126,582

13
 Cost Forcasting Three Methods (7 B)
• A second method for determining the forecasted cost at completion assumes that, regardless of the efficiency rate the project or work package has experienced in the past, the work to be
performed on the remaining portion of the project or work package will be done according to budget.

• Forecasted cost at completion =

Cumulative actual cost+ (Total budgeted cost – Cumulative earned value)

• For the packaging machine project, the forecasted cost at completion is given by:

FCAC = $68,000 + ($100,000 – $54,000)

= $68,000 + $46,000

= $114,000

13
 Cost Forcasting Three Methods (7C)
• A third method for determining the forecasted cost at completion is to re-estimate the costs for all the remaining work to be performed and then add this re-estimate
to the cumulative actual cost.

• FCAC = CAC + Re-estimate of remaining work to be performed

13
 Cost Control (8 A)
• The key to effective cost control is to analyze cost performance on a regular and timely basis.

• It’s crucial that cost variances and inefficiencies be identified early so that corrective action can be taken before the situation gets worse.

• Cost control involves the following:

– Analyzing cost performance to determine which work packages may require corrective action

– Deciding what specific corrective action should be taken

– Revising the project plan—including time and cost estimates—to incorporate the planned corrective action

14
 Cost Control (8 B)
• When evaluating work packages that have a negative cost variance, you should

– focus on taking corrective actions to reduce the costs of two types of activities:

• Activities that will be performed in the near term. If you put off corrective actions until some point in the distant future, the negative cost variance may deteriorate.

• Activities that have a large cost estimate. Taking corrective measures that reduce the cost of a $20,000 activity by 10 percent will have a larger impact than totally eliminating a

$300 activity

14
 Cost Control (8 C)
• There are various ways to reduce the costs of activities.

– One way is to substitute less expensive materials.

– Another approach is to assign a person with greater expertise or more experience to perform or help with the activity.

– Reducing the scope or requirements is another way to reduce costs.

– Increasing productivity through improved methods or technology.

• In many cases, there will be a tradeoff—reducing cost variances will involve a reduction in project scope or a delay in the project schedule.

• The key to effective cost control is aggressively addressing negative cost variances and cost inefficiencies as soon as they are identified.

14
 Managing Cash Flow
• It is important to manage the cash flow on a project.

• Managing cash flow involves making sure that sufficient payments are received from the customer in time so that you have enough money to cover the costs of performing the project.

• The key to managing cash flow is to ensure that cash comes in faster than it goes out.

• The contractor might try to negotiate payment terms that require the customer to do one or more of the following:

– Provide a down payment at the start of the project.

– Make equal monthly payments based on the expected duration of the project.

– Provide frequent payments, such as weekly or monthly payments rather than quarterly payments.

• The worst scenario from the contractor’s point of view is to have the customer make only one payment at the end of the project.

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

18
 Risk Management

Projects can fail for a number of reasons and the risks

are always high. While a project manager cannot
eliminate risk, he/she can prevent or mitigate its
impacts by using risk management.
“If You Don’t Actively Attack the Risks,
The Risks Will Actively Attack You.”

-Tom Gilb
 Some definitions of risk

• Risk management is the process of identifying, analyzing, controlling, and reporting risk.

• an uncertain even or condition that, if it occurs, has a positive or negative effect

• The two characteristics of a risk in project management are the following:

– It stems from the elements of uncertainty

– It might have negative or positive effects on meeting the project objectives

 Some definitions of risk

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

It relates to future:

Risk Planning involves speculating about future events. The future is inherently uncertain. Some things which seem obvious when a particular project is over, for example that the costs were under-estimated or that a
new technology was overly difficult to use, might not have been so obvious during planning

It involves cause and effect

For example, a ‘cost over-run’ might be identifies as a risk, but does not say what caused it. Was it, for example, an inaccurate estimate of effort, the use of untrained staff, or a poor specification?

A good definition of a specific risk identifies a situation (or hazard) and a particular type of negative outcome.
 Boehm’s top 10 development risks

Risk Risk reduction techniques

Personnel shortfalls Staffing with top talent; job matching; teambuilding;
training and career development; early
scheduling of key personnel

Unrealistic time and cost Multiple estimation techniques; design to cost;

estimates incremental development; recording and analysis
of past projects; standardization of methods

Developing the wrong Improved software evaluation; formal specification

software functions methods; user surveys; prototyping; early user
manuals

Developing the wrong Prototyping; task analysis; user involvement

user interface
 Boehm’s top ten risk - continued

Gold plating Requirements scrubbing, prototyping,

design to cost
Late changes to Change control, incremental development
requirements
Shortfalls in externally Benchmarking, inspections, formal
supplied components specifications, contractual agreements, quality
controls

Shortfalls in externally Quality assurance procedures, competitive

performed tasks design etc
Real time performance Simulation, prototyping, tuning
problems
Development Technical analysis, cost-benefit analysis,
technically too difficult 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 Planning
Formulation

Analysis

Interpretation

Risk
Management

Risk Abatement
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 Risk Qualitative

Management Identification Risk Analysis

Risk Risk Quantitative

Monitoring and Response Risk Analysis
Control Planning
 Planning Risk Management
Risk Management Planning is the process used to decide how the risk management activities for the project at hand will be performed

The major goals for planning the risk management are threefold:

– Ensure that the type, level and visibility of Risk management are proportionate with actual risk involved in the project and the importance of the project to the organization

– Secure sufficient resources, including time for risk management activities and

– Set up an agreed-upon basis for evaluating risks

To be specific, you use the risk management planning process to determine the following:

– How to approach the risk management activities for this project

– How to plan the risk management activities

– How to execute the risk management activities

 Risk identification

Risk Identification determines which risks might affect the project and documents their characteristics.

Participants in risk identification activities can include the following, where appropriate:

– Project Manager

– Project Team Members

– Risk Management team (if assigned)

– Subject matter experts from outside the project team

– Customers, end users, other project managers, stakeholders and risk management experts
 Risk identification Tools and Techniques

Documentation Reviews:
• A structured review may be performed of project documentation, including
plans, assumptions, prior project files and other information.
• The quality of the plans, as well as consistency between those plans and
with the project requirements and assumptions can be indicators of risk in
the project

Information Gathering Techniques:

• Brainstorming
• Delphi Technique
• Interviewing
• Root Cause Identification
• Strengths, Weaknesses, Opportunities and threats (SWOT)
Analysis
 Risk identification Techniques:
2. Information Gathering Technique : Brainstorming

• The goal here is to get a comprehensive list of potential risks so that no risk goes unidentified.

• The project team, along with the relevant experts from different disciplines, can participate in the brainstorming session

• Brainstorming is better performed under the guidance of a facilitator

• You can use the categories of risk to keep the session focussed on the issue
 Risk identification Techniques:
2. Information Gathering Technique : Delphi Technique

• The goal here is for experts to reach a consensus without biases toward each other.

• The Delphi technique is used to ensure that it is the quality of the information and the argument that are important, not who is saying them.

• A facilitator circulates a questionnaire among the experts to solicit ideas about the risks of the given project.

• The experts respond anonymously.

• The responses are compiled and circulated among the participating experts for further evaluation without attaching a name to a response.

• It might take few iterations before a general consensus is reached

 Risk identification Techniques:
2. Information Gathering Technique : Interviewing

• This is one of the common methods used for information-gathering for risk identification.

• You interview the appropriate stakeholders and subject matter experts to gather information that will help identify risks for the project at hand.
 Risk identification Techniques:
2. Information Gathering Technique : Root Cause Identification

• A powerful way to identify risk is to look for anything in the project that might generate a risk.

• In other words, if you can spot a potential cause for risks, it’s simple to identify the risks resulting from that cause.

• Furthermore, if you know the cause of a risk, it helps to plan an effective response.

• You can also look for risks at the opposite side of cause-that is impact.
 Risk identification Techniques:
3. Information Gathering Technique : Checklist Analysis

• The carefully prepared a checklists in any process are great no-brainer time savers

• The project in the same organisation will more often than not have similarities

• As a result, you can develop a risk identification checklist based on the information gathered from a similar set of projects previously performed.
 Risk identification Techniques:
4. Information Gathering Technique : Assumption Analysis

• Assumptions in the project scope statement represent uncertainties. You analyse these assumptions to identify the risks

• Assumption analysis is the technique used to examine the validity of the assumptions and thereby to identify the risk resulting from the inaccuracies, inconsistencies or

incompleteness of each assumption.

• For example, assume that there is only one person in the organization who has a rare skill needed for the project. An obvious assumption would be that the person will not quit the

organization before completing the assignment. The inaccuracy of this assumption amounts to the risk
 Risk identification Techniques:
5. Information Gathering Technique : Diagramming Techniques

These techniques use diagrams to identify risks by exposing and exploring the risks’ causes

Cause-and-effect Diagram : A cause-and-effect diagram illustrates how various factors (causes) can be linked to potential problems (effects)

Flowchart Diagram: A flowchart depicts how the elements of a system are related to each other and shows the logical flow of a process. By examining the flowchart of a process, the risk management team can identify the

points of potential problems in the flowchart diagram.

Influence Diagram : An influence diagram is a graphical representations of situations that shows relationships among various variables and outcomes, such as casual influences and time-ordering of events. By examining

these diagrams, the risk management team can recognize the potential problem areas and thereby identify risks.
 The Output of Risk identification
Risk Register

The Risk register is a document that contains the output of the risk identification process:

– List of identified Risks

– List of the root causes of the risks – This is a list of events or conditions that might give rise to the identified risks

– Updated Risk Categories: Risks categories were originally identified in the risk management planning process. However, in the process of identifying risks new categories of risk may be discovered or
existing risk may be modified.

– List of potential risk Responses

The results of the risk identification process usually lead to the qualitative risk.

• Depending upon the project and experience of the risk management team, risk identification might lead directly to the quantitative risk analysis and even to risk response planning
 Analyzing Risk

After risks have been identified, You need to answer two main questions for each identified risk:

– What are the odds that the risk will occur and

– If it does, what will its impact be on the project objectives?

You get the answer by performing risk analysis:

– Qualitative Risk Analysis

• This is used to prioritize risks by estimating the probability of their occurrence and their impact on the project

– Quantitative Risk Analysis

• This is used to perform the numerical analysis to estimate the effect of each identified risk on the overall project objectives and deliverables
 Analyzing Risk : Qualitative Risk Analysis

Prioritizing risks based on their probabilities of occurrence and their impact if they do occur in the central goal of the qualitative risk analysis.

Techniques used for Qualitative Risk Analysis involve estimating probability and impact

• Risk Probability and Impact Assessment:

– Risk probability refers to the likelihood that a risk will occur, and impact refers to the effect the risk will have on a project objective if it occurs

– The probability for each risk and the impact of each risk on project objectives, such as cost, quality, scope and time, must be assessed

– Methods include holding meetings, interviewing, considering expert judgment and using an information base from previous projects

– A risk with a high probability might have a very low impact, and a risk with a low probability might have a very high impact.

• To prioritize the risk, you need to look at both probability and impact
 Analyzing Risk : Qualitative Risk Analysis
Probability and impact Matrix

– The prioritization can be performed by using the probability and impact matrix – a lookup table that can be used to rate risk based on where it falls both on the probability scale and on the impact scale

A Risk Probability and Impact Matrix for an Objective

Probability Impact
0.00 0.05 0.15 0.25 0.35 0.45 0.55 0.65 0.75 0.90
0.10 R11 R12 R13 R14 R15 R16 R17 R18 R19
0.30 R21 R22 R23 R24 R25 R26 R27 R28 R29
0.50 R31 R32 R33 R34 R35 R36 R37 R38 R39
0.70 R41 R42 R43 R44 R45 R46 R47 R48 R49
0.90 R51 R52 R53 R54 R55 R56 R57 R58 R59

Risk R45 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
Remember
–and impact
Higher value matrix
of a riskand what
on the they mean
probability depends
scale means upon
– Greater
thelikelihood
projectof and
risk occurrence
the organization
– 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
Cost=$50,000 Implementation
Probability=40% Failed
Impact=$2,00,000
Loss of Revenue
Update or Build
from scratch Implementation
Build from Scratch Successful
Cost=$70,000

Implementation
Probability=10% Failed

Impact=$2,00,000
Loss of Revenue
Example of Decision Tree Diagram
 Analyzing Risk : Quantitative Analysis Techniques

Option Initial Risk Cost Probability EMV for Risk Total Cost
Cost
Update $ 50,000 $ 2,00,000 40% 0.40*$2,00,000 50,000+80,000
= $80,000 = $1,30,000
Build From $ 70,000 $ 2,00,000 10% 0.10*2,00,000 $70,000+$20,000
Scratch =$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 - RE )/ (cost of risk reduction)

before after

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

RRL > 1.00 therefore worth doing

 Planning the Risk Response: Response Strategies for Opportunities

Use “SEE” approach to deal with the opportunities presented by the positive risks

– Share

– Exploit

– Enhance

• Share: Sharing a positive risk that presents an opportunity means transferring the ownership of the risk to another party that is better equipped to capitalize on the opportunity.

• Exploit: Exploiting an opportunity means ensuring that the opportunity is realized – that is, the positive risk that presents the opportunity does occur. This is accomplished by eliminating or minimizing the uncertainty

associated with the risk occurrence. For example, Provide better quality than planned to beat a competitor.

• Enhance: This strategy means increasing the size of the opportunity by increasing the probability, impact or both. You can increase the probability by maximizing the key drivers of the positive risks or by strengthening the

causes of the risks.

 Planning the Risk Response:
Response Strategies for both Threats and Opportunities

There are two response strategies that you need to plan for the risks for which you need to take either a conditional action or no action

Acceptance: Acceptance of a risk means to let it be. Generally, it is not possible to take action against all the risks. Depending upon the probabilities and impacts, some risks will simply be accepted: There are two kinds of acceptance:

– Passive Acceptance that requires no action

– Active Acceptance that requires a condition action, called a contingent response

• Contingency: Generally speaking, contingency means a future event or condition that is possible but cannot be predicted with certainty. So, your action will be contingent upon the condition- that is- it will be executed only if

the condition happens.

– In risk management a contingent response, is a response that is executed only if certain predefined condition happens.
 Output of the Risk Response Planning

1. Risk Register Updates : The appropriate risk responses planned and agreed upon by the risk management team are included in the risk register. The responses to high and moderate risks are entered in details, while the low-priority risks can be put

on a watch list for monitoring.

After the risk register is update, it included the following main elements:

– A list of identified risks, descriptions of the risks, root causes of the risks, WBS elements affected by the risks, and the impacts of the risk on the project objectives

– Roles and responsibilities in managing the risks- that is, risk owners and the responsibilities assigned to them

– Results from qualitative and quantitative risk analyses, including a prioritized list of risks, probabilistic analysis of the project objectives and a list of risks with time urgency

– Planned and agreed-upon risk response strategies and specific actions to implement each strategy

– Budget and Schedule requirements to implement the planned responses, including the contingency reserve, which is the amount of funds, time or both needed in addition to the estimates in order to meet the organization’s and stakeholder’ risk tolerances and thresholds

– Fallback plans in case the planned responses prove to be inadequate

2. Risk Related Contractual Agreements- might results from transferring the risks

3. Project management Plan Updates

 Risk Response Control

• Risk response control involves executing the risk management plan in order to respond to risk events over the course of the project.

• When changes occur, the basic cycle of identify, quantify, and respond is repeated.

• It is important to understand that even the most thorough and comprehensive analysis cannot identify all risks and probabilities correctly- control and

iteration are required.

Tools and Techniques for Risk Response Control

– Workarounds. Workarounds are unplanned responses to negative risk events. Workarounds are unplanned only in the sense that the response was not defined in advance of the

risk event occurring.

– Additional risk response development. If the risk event was not anticipated, or the effect is greater than expected, the planned response may not be adequate, and it will be necessary

to repeat the response development process and perhaps the risk quantification process as well.
 Output From Risk Response Control

Corrective action. Corrective action consists primarily of performing the planned risk response (e.g., implementing contingency plans or workarounds).

Updates to risk management plan. As anticipated risk events occur or fail to occur, and as actual risk event effects are evaluated, estimates of probabilities and value,

as well as other aspects of the risk management plan, should be updated.

Monitoring and Controlling the Projects
 Introduction
Executing a project means

– Executing the project work according to the project management plan based on some baselines, such as a schedule baseline, a scope baseline, and a cost baseline

• Monitoring : Watching the course

• Controlling : Taking action to either stay the course or change the wrong course

• Monitoring includes

– measuring the project performance,

– collecting and distributing information about the project performance and

– evaluating the performance information to see the trends.

• Continuous monitoring helps the project management team identify the areas that need to be controlled closely by, for example, taking corrective or preventive actions
 Monitoring and Controlling
Some of the major tasks involved in monitoring and controlling the project are actions:

• Monitoring project performance by measuring it against the project management plan in terms of parameters such as cost, schedule and scope

• Monitoring the project by collecting information to support status reporting progress measurement and predictions and then distributing this information among the stakeholders

• Evaluating performance to determine whether it needs to be controlled by taking corrective or preventive actions.

• Monitoring risks by tracking and analyzing the already identified project risks and by identifying new risks.

• Controlling risk by managing the execution of risk response plans when the risks occur

• Maintaining an accurate and timely information base regarding the project as it progresses.

• Monitoring and controlling changes and monitoring the implementation of approved changes
 Monitoring and Controlling
A project is monitored and controlled using the monitor and control project work process, which is a high-level process that is performed by executing more specific processes, such as cost control, schedule control and scope

control

Monitoring and Integrated Change

Control Project Work Control

Cost Manage Quality Risk Schedule Scope

Control Project Control Monitoring Control Control
Plan and
Controlling

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 • Project Management Approved and Rejected
• Recommended Items: Methodology Items:
 Corrective Actions • Project Management  Change Request
 Preventive Actions Information Systems  Defect Repairs
 Defect Repairs • Expert Judgment  Corrective Actions
• Project Management Plan and
• Work Performance  Preventive Actions
Information 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
• Output of quality
planning:
 Quality Management
Plan
 Quality Metrics
 Quality Checklist
• Output of direct and
manage project execution
• Approved change request
• Organizational Process
Assets
Tools and Techniques Output
• Seven basic tools of • Quality Control
quality: Measurement
 Flowcharts • Recommended Items:
 Scatter diagram  Corrective Actions
 histogram  Preventive Actions
 Pareto diagram  Defect Repairs and
 control chart  Change of request
 cause and effect • Validated Items:
diagram  Deliverables and
defect repair
• Statistical Sampling • Updates:
• Inspection  Project management
• Defect Repair Review 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

Upper control limit

99

95 Mean

92
Lower 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
 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

Time Methods

Shutdown Need
Periods
Efficiency

Efficiency of
Accuracy
Night Shifts

Delay in Web Site

Release
Hiring Testing
Environment

Shutdown
Periods
Too many Development
Commitments Environment

People Environment
An example of cause and effect diagram
 Output of Quality Control
The quality control measurements and recommendations based on those measurements are the obvious outputs items of the quality control process.

Recommended Items:

– Recommended Corrective Actions

– Recommended Preventive Actions

– Recommended Defect Repair

– Request Changes

Validated Items

– Validated Defect Repair

– Validated Deliverables

Updates

Project management Plan

Quality Baseline
Understanding Project Closure
 Understanding Project Closure
Project closure refers to a set of tasks that are required to formally end the project. There are two kinds of projects that you need to close formally:

Completed Projects : A project that has met its completion criteria falls into this category

Terminated Projects: A project that was terminated before its completion falls into this category. A project can be terminated at various stages for various reasons. Following are some examples:

– The project management plan is not approved for whatever reason

– The project has been executing but you have run out of resources and no more resources are available

– The project has been cancelled because it was going nowhere

– The project has been indefinitely postponed because there is not a large enough market for the product it would produce
 Understanding Project Closure
The process of closure consists of two kinds of tasks:

– Establish procedures to co-ordinate the activities needed to close the project

– Implement the procedures

There are two aspects of closing a project:

Administrative closure:

– Performing administrative closure of a project includes obtaining final acceptance for the project deliverables, analyzing the project’s success or failure, gathering lessons learned, archiving project information and releasing project
resources.

– How will these activities be performed and coordinated, any by whom? For that, you establish an administrative closure procedure for your project that will take into account the relevant policies and procedures of the performing
organization

Contract Closure

Contract closure includes settling and closing all the contracts associated with the project. To carry out and co-ordinate the activities needed for the contract closure, you define the contract closure procedure
 Understanding Project Closure

Close
1. Establish procedures for administrative
Project
closure and contract closure
2. Implement Administrative Closure

Contract
1. Implement Contract Closure
Closure

Fig. The process to close the project

 Integrated Change Control Process
Input Tools and Techniques Output
• Project Management Plan • Project Management  Administrative
• Deliverables Methodology closure procedure
• Work Performance • Project Management  Formal Acceptance
Information Information Systems for the final product
• Contract Documentation • Expert Judgment  Updates to
• Organizational Process organizational
Assets process assets
• Enterprise Environmental  Contract closure
Factors procedrue
 Output of the Project Closure

The output of the close project process contains three kinds of elements

– Closing procedures

– Acceptance of the project deliverables by the customer and

– Archival of project-related documents

 Output of the Project Closure
Administrative Closure procedure:

– This procedure specifies the step-by-step methodology for the administrative closure of the project, which includes specifying all the necessary activities, roles and responsibilities of the project team member who

will participate in the closure process. The activities defined by this procedure include the following:

• Activities to define the requirement for getting approval from the stakeholders, such as customers and the sponsor on the project deliverables and the approved changes which were supposed to be

implemented

• Activities that are necessary to satisfy the project completion or exit criteria

• Activities related to the project completion, such as:

– Confirm that the project has met all requirements

– Verify that all deliverables have been provided and accepted
– Verify that the completion or exit criteria have been met
 Output of the Project Closure

Formal Acceptance for the Final Product:

– This includes handing over the final product to the customer and getting formal acceptance for it – for example, in the form of a receipt that contains statement to the effect that the requirement of the project have

been met, including the terms or the contracts

 Output of the Project Closure
Updates to Organizational process Assets:

– Acceptance Documentations

• This is the documentation that proves that the fulfillment of the project requirement have been confirmed, completion of the project has been verified and the product has been formally accepted by the customer.

– Project Closure Documentation

• In Additions to the acceptance documentation, you should also archive the other project closure documents, such as the closure procedures and the handing-over of project deliverables to an operation group. If the project was
terminated, then the formal documentation indicating why the project was terminated should be included in the archive

– Project Files Archive

• This includes the documents from the projects’ lifecycle such as the project management plan, risk register, planned risk responses, and baselines for cost, schedule, scope and quality

– Lessons-Learned database

• The documentation on lessons learned should be saved in the organizations knowledge database so that future projects can benefit from it

– Contract Closure Procedure

• This procedure is developed to formally close all contracts associated with the project. It specifies a step-by-step methodology to execute activities needed to close the contract. The roles and responsibilities of the team
members who will be involved in the closure process are also specified.
 Performing Contract Closure
A project might include work that was procured and that’s where legal agreements, such as contracts, come into the picture. The contracts are closed at the end of a project or a phase by using the contract closure process. Strictly speaking, the contract

closure process is used to accomplish the following two goals:

– Close all the contract applicable to the project

– Receive verification (if you are seller) or issue verification (if you are a buyer) that all the procured deliverable were received and accepted. In this respect, the contract closure process supports the administrative closure of the project.

• If the project terminates without completion, you still need to go through the contract closure process, if there is a contract. Usually a contract contains the contract termination clause, which contains the terms of the

project termination, including the rights and responsibilities of the parties in case of the; project’s early termination
 Performing Contract Closure
Closing the contract means that procured work is completed with all its requirement and is accepted.

Generally, it is accomplished by a formal notice from the buyer to the seller, which might come, for example, through the buyer’s authorized administrator
 The Finishing Touch – Reviewing the project
Part of the administrative closure is to analyze project success or failure. You can accomplish this by collecting and generating the project evaluation information, such as what went well and what did not

Some of this information already exists in the work performance reports. However, the final information can be gatheredin various ways, such as a post-project review meetings with the team or a questionnaire

The most important output of the review are the lessons learned.

The review should be comprehensive and should cover the following:

– Both the technical and non-technical components

– Both positive and negative aspects – that is, the things that went well and the things that did not go well

– All stages and phases of the project

 The Finishing Touch – Releasing the Resources
For the effective and efficient use of the organizational resources, it is imperative that they be release in an efficient and proper manner.

The release procedure might be included in the resource planning – for example, the staff management plan should address the issue of releasing the human resources

Following are some suggestions to consider for properly releasing the human resources:

– Although it is possible that different team members will be released at different times, at the project closure you should organize some closure events to honor and than the project team members, including the contractors, for their
contributions.

– Plan ahead, and do not wait until the last minute. Communicate with the functional manager ahead of time about when a staff member is going to be released

– Work closely with you organizations human resource department, which might have some guidelines or procedure that you need to follow

– Write recommendation letters for team members who have mad the outstanding contributions to the project
Solution Unit Test 1

Software Project Management

Q1a)

Why is it important to determine the critical path of a project? What happens if activities on this path are delayed? What happens if activities on this path
are accelerated?

• If any activity on the critical path is delayed, the whole project will be delayed, so it is important to know what the critical path is. If any of these activities
are accelerated, the project completion date will also be accelerated.
Q1b)

Give examples of situations in which an individual might develop a request for proposal.

• There are many possible answers to this question. Some examples might include an RFP for a new in-ground pool, a new deck, or a new house.
Q1c)

How do customers evaluate proposals? What factors might they consider?

• Customers evaluate contractors’ proposals in many different ways.

– Some customers first look at the prices of the various proposals and select, for example, only the three lowest-priced proposals for further evaluation.

– Other customers initially screen out those proposals with prices above their budget or those whose technical section doesn’t meet all the requirements stated in the RFP.

– Other customers, especially on large projects, create a proposal review team that uses a scorecard to determine whether each proposal meets all requirements in the RFP and to rate the proposal against
predefined evaluation criteria, such as price, schedule, capabilities, and experience.
Q1d)

Define proposal, and describe the purpose of a proposal.

• A proposal is a selling document and its purpose is to convince the customer that you understand what the customer wants and that you are the best one for

the job.
Q1e) Why should a project have a well-defined reporting period? During each reporting period, what kinds of data need to be collected?

• A regular reporting period should be established for comparing actual progress with planned progress. This must be done on a regular basis to ensure the project is progressing as expected. Reporting may be daily,
weekly, bi-weekly, or monthly, depending on the complexity or overall duration of the project. If a project is expected to have an overall duration of a month, the reporting period might be as short as a day. On the other
hand, if a project is expected to run five years, the reporting period might be a month.

• During each reporting period two kinds of data or information need to be collected:
1. Data on actual performance. This includes

• the actual time that activities were started and/or finished

• the actual costs expended and committed

2. Information on any changes to the project scope, schedule, and budget. These changes could be initiated by the customer or the project team, or they could be the result of an unanticipated occurrence such as a natural disaster, a labor
strike, or the resignation of a key project team member.
 Q2) Calculate the ES, EF, LS, and LF times and the slack for each activity in the figure below and identify the critical path for the project. Can the project be completed in 30 weeks?

Activity ED ES EF LS LF TS
1. Prob. Def. 2 0 2 -5 -3 -5

2. Sys. Analysis 5 2 7 -3 2 -5
3. Design I/O 3 7 10 6 9 -1
4. Design DB 15 7 22 2 17 -5
5. Develop Input 8 10 18 11 19 1
6. Develop Output 10 10 20 9 19 -1
7. Develop DB 2 22 24 17 19 -5
8. Test System 6 24 30 19 25 -5
9. Implement 5 30 35 25 30 -5

No, this project cannot be completed within 30 weeks. With the current
estimates, it will take 35 weeks. The most critical path is: 1-2-4-7-8-9.
 Q2) Assume that “Systems Analysis” actually finished at 8 weeks, “Design Input & Output” actually finished at 15 weeks, and “Design Database” actually finished at 19 weeks. Recalculate the expected project completion

time. Which activities would you focus on in order to get the project back on schedule?

Activity ED ES EF LS LF TS AF
1. Prob. Def. 2
2. Sys. Analysis 5 8
3. Design I/O 3 15
4. Design DB 15 19
5. Dev. Input 8 15 23 11 19 -4
6. Dev. Output 10 15 25 9 19 -6
7. Dev. DB 2 19 21 17 19 -2
8. Test System 6 25 31 19 25 -6
9. Implement 5 31 36 25 30 -6

The project has slipped even further. With the current estimates, it will take
36 weeks. Attention should be given to all activities since they all have
negative slack. However, the path 6-8-9 is the most critical
Quiz – Software Planning
________________ is the systematic arrangement of tasks to accomplish an objective.

– scheduling

– planning

– team building

– controlling

• ANSWER: B
• The plan becomes a benchmark against which ______ progress can be compared.

– actual

– planned

– future

– expected

• ANSWER: A
• By participating in ____________ of the work, individuals will become committed to accomplishing it.

– planning

– controlling

– discussing of

– timing

• ANSWER: A
• The _______ step in the planning process is to define the project objective

– first

– second

– third

– fourth

• ANSWER: A
• The project __________ must be clear, attainable, specific, and measurable.

– a. environment

– b. cycle

– c. objective

– d. work forms

• ANSWER: C
• For a project, the objective is usually defined in terms of scope, _______, and cost.

– a. plan

– b. schedule

– c. controls

– d. packages

• ANSWER: B
• The _____________ breaks a project down into manageable pieces, or items, to help ensure that all of the work elements needed to complete the

project work scope are identified.

– work package plan

– work budget plan

– work breakdown staff

– work breakdown structure

• ANSWER: D
• _________ Is a hierarchical tree of end items that will be accomplished or produced by the project team during the project.

– work package plan

– work budget plan

– work breakdown staff

– work breakdown structure

• ANSWER: D
• A WBS subdivides the project into smaller pieces called _____________.

– object codes

– task statements

– work items

– work loads

• ANSWER: C
• The lowest-level item of any one branch is called a ___________.

– object item

– task statements

– work package

– work loads

• ANSWER: C
• The ___________________ is a method used to display, in tabular format, the individuals responsible for accomplishing the work items in the WBS.

– responsibility matrix

– resource map

– responsibility web

– task structure

• ANSWER: A
• A _____________ is defined as a piece of work that consumes time.

– action

– activity

– element

– work object

• ANSWER: B
• When all the detailed activities have been defined for each of the work packages, the next step is to graphically portray them in a __________________
that shows the appropriate sequence and interrelationships to accomplish the overall project work scope.

– bubble diagram

– network ladder

– network diagram

– responsibility chart

• ANSWER: C
• The Gantt chart combines the two functions of _____________________.

– planning and leveling

– scheduling and evaluating

– planning and scheduling

– scheduling and controlling

• ANSWER: C