Software project management

Project Management

August 2007

SyllabusCourse 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 uncertaintyProject 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 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 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 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 RegulationsApplication 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 EnvironmentCultural and Social EnvironmentInternational and Political EnvironmentPhysical Environment

•General Management Knowledge & Skills

•Interpersonal SkillsEffective CommunicationInfluencing the OrganizationLeadershipMotivationNegotiation and conflict ManagementProblem 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

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

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

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

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

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

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

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

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

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

10. The RFP should indicate the due date by which the customer expects potential contractors to submit

proposals

Need Identification : Request for Proposal - Guidelines

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

1.The contractor’s experience with similar projects

2.Technical approach proposed by the contractor

3.The schedule. Will the contractor be able to meet or beat the required schedule?

4.The cost.

1. If the estimate is based on time and materials, are the costs reasonable?

2. Have any items be left out

3. Does it appear that the contractor has submitted a low cost estimate but will add

costs after the project is under way, resulting in final costs that are much higher

than the original estimate?

12. In rare cases an RFP will indicate the funds the customer has available to spend on the; project.

Need Identification : Soliciting Proposal

Once the RFP has been prepared, the customer solicits proposals by notifying potential contractors that the RFP

is available.

One way for customers to do this is by identifying a selected group of contractors in advance and sending

each of them a copy of the RFP

Another approach to soliciting potential contractor is for the customer to advertise in certain business

newspapers that the RFP is available and give instructions on how interested contractors can obtain a

copy.

Proposed Solution

Proposed Solution

Lecture Learning

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

• The development of winning proposals

• The proposals preparation process and the elements that may be

included in a proposal

• Pricing considerations

• The evaluation of proposals

• Types of contracts between the customer and the contractor

Proposed Solution : Bid / No Bid Decision

Competition

– Which other contractors might also submit a proposal in response to the RFP?

– Do any of these contractors have a competitive advantage, because of either pre-

RFP marketing efforts or their previous work for or reputation with the customer?

Risk

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

Mission

Is the proposed project consistent with the contractor’s 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 dissatisfied?

– Has the contractor unsuccessfully bid on RFPs from the customer in the past?

Proposed Solution : Bid / No Bid DecisionCustomer Funds

– Does the customer really have funds available to go forward with the project? Or is the customer on a

“fishing expedition” – issuing an RFP although unsure whether the project will ever be funded? A

customer may issue an RFP with the best of intentions but do so prematurely, anticipating that the

Board of Directors will approve funding. However, if the company is having financial difficulties, the

board may decide to postpone the project indefinitely, even after proposals have been received from

interested contractors

Proposal Resource

– Are appropriate resources available to prepare a quality proposal? It is not enough for a contractor

to just prepare a proposal

– It is imperative that the proposal be of sufficient quality to have a good chance of winning. To prepare

a quality proposals, a contractor must have the appropriate people – that is, resource – to work on it.

Project Resources

Are appropriate resource available to perform the project if the contractor is selected as the winner?

Contractors need to be sure that the appropriate individuals within their organizations will be

available to work on the project.

9

Developing a Winning Proposal• A selling document – not a technical report

• Convince the customer that you are the best one to solve the problem. That is the contractor

– Understands what the customer is looking for

– Can carry out the proposed project

– Will provide the greatest value to the customer

– Is the best contractor to solve the problem

– Will capitalize on its successful experience with previous related projects

– Will do the work professionally

– Will achieve the intended results

– Will complete the project within budge and on schedule

– Will satisfy the customer

• Highlight the unique factors that differentiate you from competing contractors

• Emphasize the benefits to the customer

• Write in a simple, concise manner

• Address requirements as laid out in the RFP

• Be realistic in scope, cost, and schedule

10

Proposal Preparation

• Can be a straightforward task performed by one person or a resource-intensive effort

requiring a team

• May designate a proposal manager

• Schedule must allow time for review and approval by management

• Can be a few pages or hundreds of pages

• Customers do not pay contractors to prepare proposals

11

Proposal Contents

Proposals are organized into three sections:

• Technical Section

• Management Section

• Cost Section

11

Proposal Contents : Technical Section

The objective of the technical section of the contractor proposal is to convince the customer that the contractor

understands the need or problem and can provide the least risky and most beneficial solution.

The elements of the Technical Section are

1. understanding of the problem

– Contractor thoroughly understands the problem to be solved

– Establish the basis for the solution proposed later in the technical section

2. proposed approach or solution

– A description of how the contractor would collect, analyze and evaluate data and information about the

problem

– Methods that would be used by the contractor to evaluate alternative solutions or further develop the proposed solution to the problem

– The rationale for the proposed approach or solution. This rationale could be based on experiments previously conducted by the contractor, the contractor's experience in solving similar problems or a unique patented technology the contractor would use to solve the problem

– Confirmation that the proposed solution or approach would meet each of the physical, operational and performance requirement stated in the customer's RFP

11

Proposal Contents : Technical Section

3. benefits to the customer

• The contractor should state how the proposed solution or approach would benefit the customer.

• Benefits could be quantitative or qualitative and could include cost savings; reduced processing time; reduced inventory; better customer service; less scrap, rejects or errors, ; improved safety conditions; more timely information and reduced maintenance

• This portion of the proposal should help convince the customer of the value of the proposed approach compared with proposals from competing contractors

12

Proposal Contents : Management Section

Objective

to convince the customer that the contractor can do the proposed work and achieve the intended results

The Management Section should contain the following elements:

– description of work tasks

– deliverables

– project schedule

– project organization

– related experience

– equipment and facilities

13

Proposal Contents : Cost Section

The objective of the cost section of the contractor proposal is to convince the customer that the contractor’s price for the proposed project is realistic and reasonable.

The cost section usually consist of

• Labor :

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

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

– The estimates should be realistic

• Materials

• subcontractors and consultants

• equipment and facilities rental

• travel

• documentation

• Overhead

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

• escalation

• contingency or management reserve

• fee or profit

14

Pricing Considerations

Be careful not to overprice or underprice the proposed project

Consider:

• reliability of the cost estimates

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

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

• Risk

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

• value of the project to the contractor

• customer’s budget

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

• Competition

15

Proposal Submission and Follow-Up

• Submit proposals on time

• Hand deliver expensive proposals or send 2 sets by different express mail services, if necessary

• Continue to be proactive even after submission

16

Customer Evaluation of Proposals

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

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

requirements

• Some create a proposal review team that uses a scorecard

• May submit a best and final offer (BAFO)

17

Customer Evaluation of Proposals (Cont.)

• Criteria that might be used in evaluating:

–compliance with SOW

–understanding of the problem or need

–soundness of the proposed approach

–contractor’s experience and past success

–experience of key individuals

–management capability

–realism of the schedule

–price – reasonableness, realism, and completeness

After selecting a contractor, a contract must be signed

between the customer and the contractor

A contract is:

• A vehicle for establishing customer-contractor communications and arriving at a mutual understanding and clear expectations

• An agreement between the contractor, who agrees to provide a product or service, and the customer, who agrees to pay

• Must clearly spell out the deliverables

• Two types of contracts: fixed price and cost reimbursement

18

Types of Contracts

19

Types of Contracts (Cont.)

Fixed-price contract

• Price remains fixed unless the customer and contractor

agree

• Provides low risk for the customer

• Provides high risk for the contractor

• Is most appropriate for projects that are well defined

and entail little risk

20

Types of Contracts (Cont.)

Cost-reimbursement contract

• Provides high risk for the customer

• Provides low risk for the contractor

• Is most appropriate for projects that involve risk

• Customer usually requires that the contractor regularly

compare actual expenditures with the proposed budget and

reforecast cost-at-completion

21

Contract Provisions

Misrepresentation of costs - states that it is illegal for the contractor to overstate

the hours or costs expended on the project.

Notice of cost overruns or schedule delays - outlines the circumstances under

which the contractor must notify the customer any schedule delays.

Approval of subcontractor - indicates when the contractor needs to obtain

approval before hiring a subcontractor.

Customer-furnished equipment or information - lists the items that the customer

will provide to the contractor throughout the project and the dates by which the

customer will make these items available.

Patents - covers ownership of patents that may result from conducting the project.

Disclosure of proprietary information - prohibits one party from disclosing project

confidential information, technologies, or processes.

Termination - states the conditions under which the customer can terminate the

contract, such as nonperformance by the contractor

21

Contract Provisions

• Terms of payment - addresses the basis on which the customer will make

payments to the contractor.

• Bonus/penalty payments - some contracts have a bonus provision, whereby the

customer will pay the contractor a bonus if the project is completed ahead of

schedule or exceeds other customer performance requirements. On the other

hand, some contracts include a penalty provision, whereby the customer can

reduce the final payment to the contractor if the project is not completed on

schedule or if performance requirements are not met.

• Changes. Covers the procedure for proposing, approving, and implementing

changes to the project scope or schedule.

Project Management Processes

Project Management Process

• Project management is an integrative endeavor — an action, or failure to take action, in

one area will usually affect other areas.

• The interactions may be straightforward and well-understood, or they may be subtle and

uncertain.

• For example, a scope change will almost always affect project cost, but it may or may not

affect team morale or product quality.


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


Executing

Processes

Level

of

Activity

Phase

Start

Time Phase

Finish

Planning

Processes

Closing

Processes

Initiating

Processes

Overlap of Process Groups in a Phase

1. Initiating a process

• Initiation – Committing the organization to begin the next phase of the project

2. Planning a Processes

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

been done before.

• As a result, there are relatively more processes in this section. However, the number of processes does not

mean that project management is primarily planning

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

of the information developed.

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

• These processes are subject to frequent iterations prior to completing the plan. For example, if the initial

completion date is unacceptable, project resources, cost, or even scope may need to be redefined.

• In addition, planning is not an exact science—two different teams could generate very different plans for the

same project.

2. Planning process : Core processes

• Some planning processes have clear dependencies that require them to be

performed in essentially the same order on most projects. For example,

activities must be defined before they can be scheduled or costed. These core

planning processes may be iterated several times during any one phase of a

project. They include:

• Scope Planning — developing a written scope statement as the basis for

future project decisions.

• Scope Definition — subdividing the major project deliverables into smaller,

more manageable components.

• Activity Definition - identifying the specific activities that must be 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

Information Distribution

Quality Assurance

Team Development

Quality Assurance

Source SelectionSolicitation

ScopeVerification

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 ifthey comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance.

– Performance Reporting —collecting and disseminating performanceinformation. This includes status reporting, progress measurement, andforecasting.

– Risk Response Control —responding to changes in risk over the courseof the project.

Performance Reporting

Overall Change Control

Scope change Control

ScheduleControl

Cost Control

QualityControl

RiskResponse 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

222

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

333

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

222

Project PlanThe project plan is a formal, approved document used to manage and control

project execution. It Includes :

–Project charter.

–A description of the project management approach or strategy (a summary

of the individual management plans from the other knowledge areas).

–Scope statement, which includes the project deliverables and the project

objectives.

–Work breakdown structure (WBS) to the level at which control will be

exercised.

–Cost estimates, scheduled start dates, and responsibility assignments to the

level of the WBS at which control will be exercised.

–Performance measurement baselines for schedule and cost.

–Major milestones and target dates for each.

–Key or required staff.

–Key risks, including constraints and assumptions, and planned responses

for each.

–Subsidiary management plans, including scope management plan,

schedule management plan, etc.

–Open issues and pending decisions.

222

Project Plan : Purpose

A project Plan is used to :

Guide project Execution

Document Project Planning assumptions

Document Project Planning decisions regarding alternatives chosen

Facilitate communication among stakeholders

Define key management review as to content, extend and timing

Provide a baseline for progress measurement and project control

6

Work Breakdown Structure (WBS)

• The second step is to determine what activities need to be performed.

–Approaches

• Small Projects : Brainstorm

• Complex Projects : WBS

• A list of all the activities must be developed.

• The WBS is a hierarchical tree of end items to be accomplished.

• A work item is one small piece of the project.

• A work package is the lowest-level item.

• Criteria for deciding the “How Many Levels in WBS

–The level at which a single individual or organization can be assigned

responsibility and accountability for accomplishing the work package

– the level at which you want to control the budget and monitor and collect

cost data during the project.

Work Breakdown Structure for Festival Project

7

Responsibility Matrix

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

WBS.

• It is a useful tool because it emphasizes who is responsible for each work item and shows

each individual’s role in supporting the overall project

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

• “P” indicates who has primary responsibility.

• “S” indicates who has secondary responsibility.

Responsibility Matrix for Festival Project

8

Activities, Defined• An activity is a piece of work that consumes time.

• It does not necessarily require the expenditure of effort by people

– For example: waiting for concrete to harden can take several days but does not require any human effort

• For work package “ Game Booths” in WBS the following eight detailed may be identified.

1.Design Booths

2.Specify material

3.Buy Material 4.Construct Booths

5.Paint Booths 6.Dismantle Booths

7.Move booths to festival site and reassemble

8.Dismantle booths and move to storage

9

Developing the Network Plan

• After all activities have been defined, they are graphically portrayed in a network diagram

that shows the appropriate sequence and interrelationships needed to accomplish the overall

project work scope.

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

– Program evaluation and review technique (PERT)

– Critical path method (CPM)

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

10

Gantt Charts

• Gantt charts, or bar charts, are popular due to their simplicity.

• The Gantt Charts combines the two functions of planning and scheduling

– Activities are listed down the left-hand side.

– A time scale is shown along the bottom.

– The estimated duration for each activity is indicated by a line or bar spanning the period during which the

activity is expected to be accomplished

– Column that indicate who is responsible for each task can be added to the chart.

• With Gantt Charts, the scheduling of activities occurs simultaneously with their planning

11

Gantt Charts (Cont.)

• Do not display the interrelationships of activities.

• If one activity is delayed, it is not obvious how that will affect other activities.

• Most project management software can show interdependencies with arrows.

Gantt Chart for Consumer Market Study Project

Network Diagram Techniques

• Network Techniques separate the planning and scheduling functions

• A Network Diagram is the result or output of the planning functions and is not drawn to a

time scale

• From this diagram a schedule is developed.

– Separating the two functions makes it much easier to revise a plan and calculate an updated schedule

• Different formats can be used to draw the Network diagram:

– Activity in the box (AIB) OR Activity on the node (AON)

– Activity on the arrow (AOA)

13

Activity in the Box (AIB)

• Each activity is represented by a box.

• The activity description is written in the box.

• Activity consume time, and their description usually starts with a verb

• Each activity is represented by one and only one box.

• Each box is assigned a unique activity number.

• Activities have a precedential relationship.

• Some activities may be done concurrently.

Get Volunteers

7

AIB : Sequential and Concurrent Activities

Wash Car

3Dry Car

4

Get Volunteers7

Buy Materials

8

Construct Booth

9

Paint Booth

10

Dismantle Booth

11

Clean Up

12

14

Activity on the Arrow (AOA)

• Each activity is represented by an arrow.

• The activity description is written above the arrow.

• Each activity is represented by one and only one arrow

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

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

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

Collect Data

15

Activity on the Arrow (AOA) (Cont.)

• Activities are linked by circles called events.

• An event represents the finish of activities entering it and the start of activities leaving it.

• Each event is assigned a unique activity number.

• For example, the activities shown below, “Wash Car” and “Dry Car”, have a serial relationship and are linked together by

event 2. Event 2, represents the completion of “Wash Car” and the start of “Dry Car”

1 2 3Wash Car Dry Car

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

15

Activity on the Arrow (AOA) (Cont.)

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

12

8

11

Get Volunteers

ConstructBooth

7

9 10

6

Buy Materials

PaintBooth

DismantleBooth

Clean Up

• Rules:

• Each event (circle) in the network diagram must have a unique event number – that is, not two events in the network diagram can have the same event number

• Each activity must have a unique combination of predecessor and successor event numbers

16

Dummy Activities

• In the activity-on-the-arrow format, there is a special type of activity known as a

dummy activity, which consumes zero time and is represented by a dashed arrow in the

network diagram

• Used only in the activity-on-the-arrow format for two reasons

– To help in the unique identification of activities and to show certain precedential

relationships that otherwise could not be shown.

• Used in the AOA format.

• Consumes zero time.

• Represented by a dashed arrow.

• Needed for:

– Helping in the unique identification of activities.

– Showing certain precendential relationships that otherwise could not be shown.

16

Dummy Activities• Activities A and B below both have the predecessor-successor event number

combination 1 – 2.

• This is not allowed in an AOA network diagram, because if someone referred to

activity 1-2, it would not be clear whether activity A or activity B was being discussed

1 3

A

B

16

Dummy Activities• The insertion of a dummy activity, as shown below, allows activities A and B to have

unique predecessor-successor event number combinations.

1 3

2

A

B

16

Dummy Activities

• For example Draw AOA: Activities A an B can be done concurrently. When activity

A is finished, activity C can start. When both activity A and activity B are finished,

activity D can start

1 3A 5

C

2 4B 6

D

A

2

1

B 5

4

3

C

D

Incorrect

16

Dummy Activities• An advantage of the Activity-in-the-box format is that the logic can be shown

without the use of dummy activities.

A

1C

3

B

2D

4

17

Loops

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

A

1C

3

D

4

18

Laddering

• Used for projects that have a set of activities that are repeated several times.

For example, consider a project involving the painting of three rooms. Painting each room requires

(1) preparing the room to be painted

(2) painting the ceiling and walls and

(3) painting the trim.

Assume that three experts will be available – one to do the preparation, one to paint the ceilings and

walls and one to do the trim.

Activities Performed Serially

Activities Performed Concurrently

Concurrent processing is not possible in this case, as only one expert is available for each type of activity

Laddering

19

Preparing the Network Diagram

• Ask the following questions regarding each activity:

– Which activities must be finished immediately before this activity can be started?

– Which activities can be done concurrently with this activity?

– Which activities cannot be started until this activity is finished?

20

Preparing the Network Diagram (Cont.)

• Should flow from left to right.

• Not drawn to a time scale.

• Can vary in how detailed the diagram should be.

• AIB vs. AOA is a matter of personal preference.

• AIB is the most common in project management software packages.

20

Guidelines for Preparing the Network Diagram

• If a work breakdown structure has been prepared for the project, then activities

should be identified for each work package.

• For example, figure on next slide shows a WBS for a project involving a consumer

market study and the activities that have been identified for each work package

Work Breakdown Structure for Consumer Market Study Project

20

Guidelines for Preparing the Network Diagram (contd…)

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

more detailed network.

– A summary network contains a small number of higher-level activities rather than a

large number of detailed activities.

• The level of detail may be determined by certain obvious interface or transfer points :

– If there is a change in responsibility – that is, a different person or organization

takes over responsibility for continuing the work – it should define the end of one

activity and the start of other activities

• For example, if one person is responsible for building an item and

another person is responsible for packaging it, these should be two

separate activities.

20

Guidelines for Preparing the Network Diagram (contd…)

• Activities should not be longer in estimated duration than the time intervals

at which actual project progress will be reviewed and compared to planed

progress.

– For example, if the project is a three-year endeavor and the project team

plans to review project progress monthly, then the network should contain

no activities with estimated durations greater than 30 days.

– If there are activities with longer estimated durations, they should be

broken up into more detailed activities with durations of 30 days or less

• Finally, when the entire network diagram has been drawn, it’s necessary to

assign a unique activity number to each activity

Example : Network Diagram for Consumer Market Study Project

21

ExerciseDraw a network diagram representing the following logic:

As the project starts, activities A and B can be performed concurrently. When A is

finished, activities C and D can start. When B is finished, activities E and F can start.

When activities D and E are finished, activity G can start. The project is complete when

activities C, F, and G are finished. Use both the activity-in-the-box and the activity-on-

the-arrow formats .

A C

D

B E G

F

Start Finish

21

Exercise

Activity Immediate Predecessor

1. Problem Definition —

2. Study Current System 1

3. Define User Requirements 1

4. Logical System Design 3

5. Physical System Design 2

6. System Development 4, 5

7. System Testing 6

8. Convert Database 4, 5

9. System Conversion 7, 8

1 2 5 6 7 9

3 4 8

21

Exercise

Draw a network diagram representing the following logic:

• As the project starts, activities A and B can be performed concurrently. When A

is finished, activities C and D can start. When B is finished, activities E and F

can start. When activities D and E are finished, activity G can start. The project

is complete when activities C, F, and G are finished. Use both the activity-in-

the-box and the activity-on-the-arrow formats .

21

Information System, Defined

• An information system (IS) is a computer-based system that accepts data as input,

processes the data, and produces useful information for users.

22

Planning for Information Systems Development

• The systems development life cycle (SDLC) is used to help plan,

execute and control IS development projects.

• Many people view the SDLC as a classic problem-solving approach.

23

Steps of the SDLC

• Problem definition

• System analysis

• System design

• System development

• System testing

• System implementation

24

Project Management Software

You are advised to prepare the following

• WBS

• Responsibility Matrix

• Gant Chart

• Network Diagram

Scheduling

222

Learning Objectives Estimate the duration for each activity

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

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

estimated start time

Calculate the latest times by which each activity must start and finish in order to complete the

project by its required completion time

Determine the amount of positive or negative slack

Identify the critical (longest) path of activities

4

Real World Example

US Census 2000 Project

• A US Census takes place every 10 years in the form of a questionnaire from the US Census Bureau.

Census information helps the government in making policies regarding health, education, transportation,

community services etc.

• Census participation takes only a few minutes, but it takes years for the employees of the Census Bureau.

Census 2000 was a 13-year project that’s total life cycle cost $65 billion

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

addresses as possible

• Project’s goal was 70% response rate to the 2000 Census. The Bureau implemented a plan to spread the

word about the census and stress its importance. A non-response plan was also established to reach those

that failed to complete the census

• The 2000 Census was considered to be the most accurate population count in US history. For the first

time, census data was made available on the Internet

6

Activity Duration Estimates– The first step in scheduling is to estimate how long each activity will take.

– The duration estimate is the total elapsed time for the work to be done PLUS any associated waiting

time.

– The person responsible for performing the activity should help make the duration estimate. However,

for large projects it may not be practical to have each person provide activity duration estimates .

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

activity.

Network Diagram for Consumer Market Study Project,Showing Duration Estimates

7

Project Start and Finish Times

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

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

• If a project must be completed in 130 working days, we define the project’s estimated start time as 0 and

its required completion time is day 130.

8

Schedule Calculations

• A project schedule includes:

– the earliest times (or dates) at which each activity can start and finish,

based on the project's estimated start time (or date)

– the latest times (or dates) by which each activity must start and finish in

order to complete the project by its required completion time (or date)

9

Earliest Start and Finish Times

• Earliest start time (ES) is the earliest time at which a particular activity can begin.

• Earliest finish time (EF) is the earliest time by which a particular activity can be

completed.

• EF = ES + Duration Estimate

• The ES and EF times are determined by calculating forward through the network

diagram.

• Rule: 1

– The earliest start time for a particular activity must be the same as or later than the

latest of all the earliest finish times of all the activities leading directly into that

particular activity

Earliest Start Times

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

The ES and EF times are sometimes listed in a separate schedule table

11

Latest Start and Finish Times

• Latest finish time (LF) is the latest time by which a particular activity must be

finished in order for the entire project to be completed by its required

completion time, calculated on the basis of the project’s required completion

time and the duration estimates for succeeding activities.

• Latest start time (LS) is the latest time by which a particular activity must be

started in order for the entire project to be completed by its required completion

time, calculated by subtracting the activity’s duration estimate from the

activity’s latest finish time:

• LS = LF – Duration Estimate

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

network diagram.

• Rule 2: The latest finish time for a particular activity must be the same as or

earlier than the earliest of all the latest start times of all the activities emerging

directly from that particular activity.

Latest Finish Times

12

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

Latest Start and Finish Times

• The very first activity, “Identify Target Consumers,” has an LS of –8! This means that in order to

complete the entire project by its required completion time of 130 days, the project must start 8 days

earlier than it is estimated to start.

• Like the earliest start and earliest finish times, the latest start and latest finish times are sometimes shown

in a separate schedule table

Schedule for Consumer Market Study Project,Showing Latest Start and Finish Times

13

Total Slack, Defined

• The difference between the calculated earliest finish time of the very last activity and the

project’s required completion time is the total slack (TS), sometimes called float.

• If total slack is positive, it represents the maximum amount of time that the activities on a

particular path can be delayed without jeopardizing completion of the project by its

required completion time.

• On the other hand, if total slack is negative, it represents the amount of time that the

activities on a particular path must be accelerated in order to complete the project by its

required completion time.

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

14

Critical Path

• This longest path in the overall network diagram is called the critical path.

• One way to determine which activities make up the critical path is to find which ones have

the least slack.

• All the activities with this value are on the critical path of activities.

• The values of total slack for the consumer market study project are shown in Figure on

next slide

Schedule for Consumer Market Study Project,Showing Total Slack Values

15

Critical Path

• The lowest value is –8 days.

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

16

Free Slack

• Free slack is the amount of time a particular activity can be delayed without delaying the earliest start

time of its immediately succeeding activities.

• It is the relative difference between the amounts of total slack for activities entering into the same activity.

• It is always a positive value

• In the network diagram (Figure on Next slide), there are three instances where a particular activity has

more than one activity entering into it:

– Activity 9, “Mail Questionnaire & Get Responses,” has activities 5 and 6 entering into it.

– Activity 10, “Test Software,” has activities 7 and 8 entering into it.

– Activity 11, “Input Response Data,” has activities 9 and 10 entering into it.

17

Free Slack

16

Free Slack

• The values of total slack for activities 5 and 6 are 0 and –8 days, respectively.

• The lesser of these two values is –8 days for activity 6.

• The free slack for activity 5 is the relative difference between its total slack, 0, and –8. This relative

difference is 8 days: 0 – (–8) = 8 days.

Scheduling-PERT

20

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

211

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:

pmoe tttt 46

1

2

2

6

1

op tt

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 (ts ) is given by

e

es TTZob

Pr

The standard normal variate is given by

e

es TTZ

Where eT = expected completion time of the Project

e number of standard deviations the scheduled time lies from the expected

(mean time) Variance 2 of the critical path can be known by adding variances of the critical activities

22

Example - PERT

A project is represented by the network shown below and has the following data Task A B C D E F G H I Optimistic 5 18 26 16 15 6 7 7 3 Pessimistic 10 22 40 20 25 12 12 9 5 Most likely 8 20 33 18 20 9 10 8 4 Determine the following

a) Expected task times and their variance b) The earliest and latest expected times to reach each event c) The critical path d) The probability of an event occurring at the proposed completion date if the

original contract time of completing the project is 41.5 weeks

1

3 6

2

5

4

7

E

A

F I

H B

C

D G

Activity ot pt mt

6

4 pmoe

tttt

2

02

6

tt p

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

Solution

Solution

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 = 8.42et

Variance of Critical Path = 123.6694.0429.5

It is given that sT =41.5, 8.42eT and 474.2123.6 e

Therefore, probability of meeting the schedule time is given by

e

es TTZob

Pr = Prob 52.0Z = 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

22

Learning Objectives

Perform the steps in the project control process

Determine the effects of actual schedule performance on the project

schedule

Incorporate project changes into the schedule

Calculate an updated project schedule

Control the project schedule

Project Control Process

The project control process involves :

–Regularly gathering data on project performance,

–Comparing actual performance to planned performance

–Taking corrective actions if actual performance is behind planned

performance

5


• The key to effective project control is to measure actual progress and compare it to planned progress on a timely and regular

basis and to take necessary corrective action immediately.

• Establish a regular reporting period.

• During each reporting period, collect:

– data on actual performance

– information on any changes to project scope, schedule and budget.

• If changes are incorporated, a new plan must be established.

Project management is a proactive approach to controlling a project, to ensure that the project objective

is achieved even when things don't go according to plan

6

Effects of Actual Schedule Performance• Throughout a project, some activities will be completed on time, some will be finished ahead of

schedule, and others will be finished later than the schedule

• Actual Progress – whether faster or slower than planned – will have an effect on the schedule of

the remaining uncompleted activities of the project

• Actual finish times (AFT) of completed activities will determine the earliest start and earliest finish

times for the remaining activities.

7

Incorporating Project Changes into the Schedule

• Changes might be initiated by the customer or the project team, or they

might be the result of an unanticipated occurrence.

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

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

and schedule

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

charged.

Network Diagram for Consumer Market Study Project,Showing the Critical Path

Revised Schedule for Consumer Market Study Project

8

Updating the Project Schedule

• Once data have been collected on the actual finish times of completed activities and the effects of any

project changes, an updated project schedule can be calculated based on the actual finish times of

completed activities.

• Changes in the Network diagram studied in last class

– Completed Activities

Activity 1: “Identify Target Consumers” actually finished on day 2

Activity 2: “Develop Draft Questionnaire” actually finished on day 11

Activity 3 : “Pilot-Test Questionnaire” actually finished on day 30

– Project Changes

• It was discovered that the database to be used to prepare the mailing labels was not up

to date. A new database needs to be purchased before the mailing labels can be

prepared. This new database was ordered on day 23. It will take 21 days to get it from

the supplier

• A preliminary review of comments from the pilot test of the questionnaire indicates that

substantial revisions to the questionnaire are required. Therefore, the duration estimate

for activity 4 needs to be increased from 5 days to 15 days

Network Diagram for Consumer Market Study Project, Incorporating Actual Progress and Changes

Updated Schedule for Consumer Market Study Project Consumer Market Study Project

9

Approaches to Schedule Control Four Steps

Schedule control involves four steps:

–Analyzing the schedule to determine which areas may need

corrective action

–Deciding what specific corrective actions should be taken

–Revising the plan to incorporate the chosen corrective actions

–Recalculating the schedule to evaluate the effects of the planned

corrective actions

• If the planned corrective actions do not result in an acceptable

schedule, these steps need to be repeated

10

Approaches to Schedule Control (Cont.)

• A change in the estimated duration of any activity on that path will cause a corresponding

change in the slack for that path.

• When analyzing a path of activities that has negative slack, you should focus on two kinds

of activities:

– Activities that are near term (that is, in progress or to be started in the immediate future).

– Activities that have long estimated durations

11

Reducing the Estimated Durations

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

– One obvious way is to apply more resources to speed up an activity. Sometimes,

however, adding people to an activity may in fact result in the activity’s taking longer.

– Another approach is to assign a person with greater expertise or more experience to

perform or help with the activity.

– Reducing the scope or requirements for an activity is another way to reduce its

estimated duration.

– In an extreme case, it may be decided to totally eliminate some activities.

– Increasing productivity through improved methods or technology is yet another

approach.

12

Approaches to Schedule Control (Cont.)

• In most cases, eliminating negative slack by reducing durations of

activities will involve a trade-off in the form of an increase in costs or a

reduction in scope.

• Some contracts include a bonus provision, whereby the customer will pay

the contractor a bonus if the project is completed ahead of schedule.

• Conversely, some contracts include a penalty provision, whereby the

customer can reduce final payment to the contractor if the project is not

completed on time.

• The key to effective schedule control is to aggressively address any paths

with negative or deteriorating slack values as soon as they are identified.

13

Schedule Control for Information Systems Development

• Controlling the schedule for the development of an information system is a challenge.

• Among the changes that commonly become necessary during IS development projects are the following:

–Changes to input screens

–Changes to reports

–Changes to on-line queries

–Changes to database structures

–Changes to software processing routines

–Changes to processing speeds

–Changes to storage capacities

–Changes to business processes

–Changes to software resulting from hardware upgrades or, conversely, hardware upgrades resulting from the availability of more powerful software

14


• The software allows you to perform various control functions.

• The percent complete for each task can be entered.

• Changes to the duration estimates can be entered.

• The software will automatically revise the project schedule and the corresponding network

diagrams.

Resource Considerations

22

Learning Objectives

• Learn how to take resource constraints into account

• Determine the planned resource utilization for a project

• Level the use of resources within the required time frame

• Determine the shortest project schedule with limited resources

Technically Constrained Activity Sequence

4

Resource-Constrained Planning

• Nearly all projects have limits on available resources.

• Project delays often occur due to certain resources being unavailable.

• A network diagram can be drawn to reflect the availability of a limited number of

resources.

Resource-Constrained Planning

5

Planned Resource Utilization

• If resources are to be considered in planning, it’s necessary to indicate the amounts and types of

resources needed to perform each activity.

Painting Project Showing Needed Resources

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

5


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

• Resource utilization based on each activity’s earliest start time are said to be based on an as-soon-as-

possible (ASAP) schedule.

• Resource utilization charts based on each activity’s latest start time are said to be based on an as-late-as-

possible (ALAP) schedule.

6

Resource Leveling

• Resource leveling, or smoothing, is a method for developing a schedule that attempts

to minimize the fluctuations in requirements for resources.

• This method levels the resources so that they are applied as uniformly as possible

without extending the project schedule beyond the required completion time.

• Non critical activities are delayed beyond their earliest start times in order to maintain

a uniform level of required resources

• Example : Utilization of Painters

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

“Basement Rooms” could be delayed up to 8 days, and “Bedrooms” could be

delayed up to 6 days—all without extending the project completion time

6

Resource Leveling

Two alternative actions could be taken:

– Alternative 1. Delay the activity with the most positive slack—“Basement

Rooms” (+8 days slack)—by 6 days so that it will start after “Bedrooms” is

finished.

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

“Basement Rooms” is completed.

Resource-Leveled Utillization

Resource-Leveled Profile for Painters

7

Resource-Limited Scheduling

• Resource-limited scheduling is a method for developing the shortest

schedule when the number or amount of available resources is fixed

and cannot be exceeded.

• This method will extend the project completion time if necessary in

order to keep within the resource limits.

• When several activities need the same limited resource at the same

time, the activities with the least slack have first priority

Effect of Limited Resource Availability

what would happen if only a limited number of painters—two—were available to do the painting project.

Original Resource Utilization

Figure below shows that, as the project starts, three activities require a total of four painters

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

First Resource Allocation

This first resource allocation is shown in Figure below with the project completion going from day 12 to day

14.

Second Resource Allocation

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

Third Resource Allocation

• The third resource allocation is shown in Figure below with the project completion date remaining at day 16

8


• Provides excellent features for handling resource considerations within a project.

• Allows you to create and maintain a list of resources.

• Resources can be assigned to various tasks within a project.

• The user is informed if any resources have time conflicts or if they are over-allocated.

• Numerous resource allocation reports can be generated.

Software Software

Project Project

PlanningPlanning

Objective

• To provide a framework that enables the manager to make reasonable estimates of

resources, cost and schedule.

Task set for Project Planning

• Establish project scope

• Determine feasibility

• Analyze Risks

• Define required resources

• Estimate cost and effort

• Develop a project schedule

Various steps of planning activity

Size Estimation

Cost Estimation Development Time

Resources Requirements

Project scheduling

Size Estimation

• The estimation of size is very critical and difficult area of the project planning.

• It is difficult to establish the unit of measurement.

Line of Code

• First measurement attempt.

• Advantage of being easily recognizable and counted.

• Disagreement on what is included in line of code.

• Early users of LOC did not include data declarations, comments, or any other lines that

did not result in object code.

Line of Code (contd…)

• Conte has defined the lines of code as:

• “A line of code is any line of program text that is not a comment or blank line, regardless

of the number of statements or fragments of statements on the line. This specifically

include all lines containing program header, declarations and executable and non

executable statements.”

Disadvantage of using LOC

• It is language dependent

• They also reflect what the system is rather than what it does.

• Measuring software size in terms of LOC is analogous to measuring a car stereo by the

number of resistors, capacitors and integrated circuits involved in it production.

Function Count

• Alan Albercht (IBM 1970) developed a technique called Function Point Analysis.

• It measures functionality from users point of view.

• It deals with functionality being delivered

Function Point Analysis

• The principle of Function Point Analysis is that a system is decomposed into functional

units

• The five function units are divided in two categories:

• Data function types

– Internal Logical files

– External Interface files

• Transactional Function Types

– External Inputs

– External Outputs

– External Inquiry

internal logical

files

external inputs external

outputs

external inquiries

external interface files

Function Point Analysis

Special Features

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

• Function points can be estimated from requirement specification of design specifications, thus

making it possible to estimate development effort in early phases of development.

• Function Points are directly linked to the statement of requirements; any change of

requirements can easily be followed by a re-estimate

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

Counting Function Points

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

High.

• Organization that use FP methods develop criteria for determining whether a particular

entry is Low, Average or High

Counting Function Points

Low Average High

Functional Units Weighing Factors

External Inputs

External Output

External Inquiries

Internal Logical files

External Interface files

3 4 6

4 5 7

3 4 6

7 10 15

5 7 10

Functional Units Count complexity Complexity totals Functional Unit Totals

External Inputs

External Outputs

External Inquiries

Internal Logical files

External Interface Files

Low x 3

High x 6

Average x 4

=

=

=

Low x 4

High x 7

Average x 5

=

=

=

Low x 3

High x 6

Average x 4

=

=

=

Low x 7

High x 15

Average x 10

=

=

=

Low x 5

High x 10

Average x 7

=

=

=

Unadjusted Function Point

Procedure for Calculating UFP

ijJ

ijI

wZUFP

3

1

5

1

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

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

factors

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


1. Does the system require reliable backup and recovery?

2. Is data communication required?

3. Are there distributed processing functions?

4. Is performance critical?

5. Will the system run in an existing heavily utilized operational environment?

6. Does the system require online data entry

7. Does the online data entry require the input to be built over multiple screens or operations

Rate each factor on a scale of 0 to 5 0 1 2 3 4 5

No Influence Incidental Moderate Average Significant Essential


8. Are the master files updated online?

9. Is the inputs, outputs, files or inquiries complex?

10. Is the internal processing complex?

11. Is the code designed to be reusable?

12. Are conversion and installation included in the design?

13. Is the system designed for multiple installations in different organizations?

14. Is the application designed to facilitate change and ease of use by the user?

Rate each factor on a scale of 0 to 5 0 1 2 3 4 5

No Influence Incidental Moderate Average Significant Essential

Problem

• Consider a project with the following functional units:

• no. of user inputs = 50

• No. of outputs = 40

• No. of user enquiries = 35

• No of user files = =06

• No of external interfaces = 04

• Assume all CAF and weighting factors are average. Compute the FP for the project

Answer

ijJ

ijI

wZUFP

3

1

5

1

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

iFCAF 01.065.0

=(0.65+0.01(14*3)) = 0.65 + 0.42 = 1.07 FP = UFP * CAF =628 * 1.07 = 672

Problem

• An application has the following:

• 10 low external inputs, 12 high external outputs, 20 low internal logical files, 15 high

external interface files, 12 average external inquiries and a value of CAF of 1.10.

• What are the unadjusted and adjusted FP counts?

Answer

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

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

FP = UFP * CAF

= 452 * 1.10 = 497.2

ijJ

ijI

wZUFP

3

1

5

1

Example

Consider a project with the following parameters.

i) External Inputs

a) 10 with low complexity

b) 15 with average complexity

c) 17 with high complexity

ii) External outputs:


b) 13 with high complexity

iii) External inquiries:


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


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

Fi = 3+4+3+5+3+3+3+3+3+3+2+3+0+3=41

CAF = (0.65 + 0.01 Fi)

= (0.65 0.01 41)

= 1.06

FP = UFP CAF

= 424 1.06

= 449.44

i=1

14

Software Software

Project Project

PlanningPlanning

Software Project Planning

The overall goal of project planning is to The overall goal of project planning is to establish a pragmatic strategy for establish a pragmatic strategy for controlling, tracking, and monitoring a controlling, tracking, and monitoring a complex technical project.complex technical project.

Why?Why?

So the end result gets done on time, with So the end result gets done on time, with quality!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!

SoftwarSoftwaree

ProjectProjectPlanPlan

Project ScopeProject ScopeEstimatesEstimatesRisksRisksScheduleScheduleControl strategyControl 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!Even when you understand, nothing is guaranteed!

What is Scope?

• Software scope describes

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

– the data that are input and output

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

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

• Scope is defined using one of two techniques:

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

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

Resources

project

people

skills

number

location

reusable software

OTS components

full-experience components

new components

part.-experience components

environment

hardware

software tools

network resources

Project Estimation

• Project scope must be understood

• Elaboration (decomposition) is necessary

• Historical metrics are very helpful

• At least two different techniques should be used

• Uncertainty is inherent in the process

Estimation Techniques

• Past (similar) project experience

• Conventional estimation techniques

– task breakdown and effort estimates

– size (e.g., FP) estimates

• Empirical models

• Automated tools

Estimation Accuracy

• Predicated on …

– the degree to which the planner has properly estimated the size of the product to be built

– the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the

availability of reliable software metrics from past projects)

– the degree to which the project plan reflects the abilities of the software team

– the stability of product requirements and the environment that supports the software engineering effort.

What makes a Successful Project?

Delivering:

agreed functionality

on time

at the agreed cost

with the required quality

Stages:

1. set targets

2. Attempt to achieve targets

Difficulties/Problems of estimation

• The uniqueness of project

• Changing technology

• Subjective nature of estimating

• Political implications (conflicting interests of major stakeholders)

Cost Estimation

• Necessary to know the cost and development time.

• Estimates are needed before development is initiated.

• In many cases estimates are made using past experience as the only guide.

Cost Estimation

A number of estimation techniques have been developed and are having following attributes

in common:

• Project scope must be established in advance.

• Software metrics are used as a basis from which estimates are made.

• The project is broken into small pieces which are estimated individually.

Cost Estimation

To achieve reliable cost and schedule estimates, a number of options arise:

• Delay estimation until late in project.

• Use simple decomposition techniques to generate project cost and schedule estimates.

• Develop empirical models for estimation.

• Acquire one or more automated estimation tools.

Unfortunately, the first option, however attractive, is not practical. Cost estimates must be provided up front

Cost Estimation Models

• An Estimation model for computer software uses empirically derived formulas to predict

effort as a function of LOC or FP.

• The empirical data that support most estimation models are derived from limited sample of

projects.

• For this reason, no estimation model is appropriate for all classes of software and in all

development environment.

Model

• The model is concerned with the representation of the process to be estimated.

• A model may be static or dynamic.

• In static model, a unique variable is taken as a key element for calculating all others.

• In dynamic model, all variables are interdependent and there is no basic variable as in

static model

Model

• Single variable model: When a model makes use of a single basic variable to calculate all

others it is said to be a single variable model.

• Multivariable model: In some models , several variables are needed to describe the

software development process, and selected equations combine these variables to give the

estimate of time and cost.

The variables, single or multiple that are input to the model to predict the behaviour of a software development are called predictors

The choice of handling of these predictors are most crucial activity in estimating methodology

Static Single Variable Models

• Methods using this model use an equation to estimate the desired values such as cost, time, effort.

• Estimated values depend on same predictor (e.g. size)

• Most common equation

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

SEL Model

E = 1.4L0.93

DOC = 30.4L0.90

D = 4.6L0.26

Where

E = Effort Person Months DOC = Documentation in

number of pages and

D =duration in Months

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

Static, Single Variable Models

Walston and Felix

E = 5.2L0.91

D = 4.1L0.36

L = (E/a)1/b

L = (E/a)1/b

Productivity

• Productivity is expressed as number of lines of source code per person months

Example

• Compare the Walston-Felix model with SEL model on a software development expected to involve 8

person years effort

• Calculate the number of lines of source code that can be produced

• Calculate the duration of the development

• Calculate the productivity in LOC/PY

• Calculate the average manning.

Solution

SEL

L = (96/1.4)1/0.93 = 94264 LOC

D = 4.6(94.264)0.26 = 15 months

P = 94264 / 8 = 11783 LOC/Person Years

M = 96 P-M / 15 M

= 6.4 Persons

W-F Model

L = (96/5.2)1/0.91 = 24632 LOC

D = 4.1(24.632)0.36 = 13 months

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

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

If we look at the value of “L” it seems that SEL can produce four times as much software as W-F for the same manpower and time scale

Discussion

• Since we cannot make absolutely corrected estimation, should we on a side of under- or

over-estimation? Why?

Constructive Cost Model (COCOMO)

• Proposed by B.W. Bohem in his famous book “Software Engineering Economics” in 1981

• COCOMO is a hierarchy of software cost estimation models, which include basic,

intermediate and detailed sub models

Basic Model

• Aims at estimating in a quick and rough fashion.

• Used in small to medium size software projects.

• Three modes of software development are considered in this model: Organic, semi

detached and embedded

Basic Model

organic mode

– a small team of experienced developers develops software in a very familiar environment.

– The size of the software development in this mode ranges from small (a few KLOC) to medium (a few tens of KLOC)

Embedded Mode

– The project has tight constraints, which might be related to the target processor and its interface with the associated hardware

– The problem to be solved is unique and so it is often hard to find experienced persons, as the same does not usually available

Semi detached mode

is an intermediate mode between the organic mode and embedded mode.

Mode Project size Nature of Project Innovation Deadline Development Environment

Organic Typically 2-50 KLOC

Small size project, experienced developers in the familiar environment

Little Not tight Familiar and Inhouse

Semi detached

Typically 50-300 KLOC

Medium size projects, medium size team, Average previous experience on similar projects

Medium Medium Medium

Embedded Over 300 KLOC

Large Project, real time systems, complex interfaces, very little previous experience

Significant Tight

Complex Hardware/ interfaces required

Comparison of three COCOMO Modes

Basic Model• The basic COCOMO equations take the form

E is the effort applied in Person month

D is the development time in months

The coefficients ab

,bb

,cb

,db

are given in table below

bbb KLOCaE bd

b EcD

Project ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi detached

3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Basic COCOMO Coefficient

Basic Model

• When effort and development time are known, the average staff size to complete the

project may be calculated as:

– Average staff size = E/D persons

• When project size is known, the productivity level may be calculated as:

– Productivity P = KLOC/E KLOC/PM

• Example : Suppose that a project was estimated to be 400 KLOC. Calculate the effort and

development time for each of the three modes i.e. organic, semidetached and embedded.

Organic Mode

– E=2.4(400)1.05=1295.31 PM (Person-Month)

– D=2.5(1295.31)0.38=38.07 M

Semidetached Mode

– E=3.0(400)1.12 =2462.79 PM (Person-Month)

– D=2.5(2462.79)0.35 =38.45 M

Embedded Mode

– E=3.6(400)1.20=4772.81 PM (Person-Month)

– D=2.5(4772.81)0.32=38 M

Example

• Effort calculated for embedded mode is approximately 4 times, the effort for organic mode

• Effort calculated for semidetached mode is 2 times the effort of organic mode.

• Surprisingly, the development time is approximately the same for all three modes.

• Selection of Mode is very Important

– The selection of a mode is not only dependent on project size, but also on other parameters as Nature of

Project, Innovation, Deadline of the project, Development environment

Example

• A project size of 200 KLOC is to be developed. Software development team has average

experience on similar type of projects. The project schedule is not very tight. Calculate the

effort, development time, average staff size and productivity of the project.

Solution

• The semi detached model is the most appropriate mode. Keeping in view the size, schedule

and experience of the development team

E=3.0(200)1.12 =1133.12 PM (Person-Month) D=2.5(1133.12)0.35 =29.3 M

Average Staff Size (SS) = PersonsD

E

= persons67.383.29

12.1133

Productivity = PMKLOCE

KLOC/1765.0

12.1133

200

= 176 LOC/PM

Intermediate Model

• The basic model allowed for a quick and rough estimate, but it resulted in a lack of

accuracy.

• Boehm introduced an additional set of 15 predictors called cost drivers in the intermediate

model to take account of the software development.

• Cost drivers are used to adjust the nominal cost of a project to the actual project

environment, increasing the accuracy of the estimate.

Intermediate Model

• The cost drivers are grouped into four categories

• Product attributes

– Requires software reliability (RELY)

– Database size (DATA)

– Product complexity (CPLX)

• Computer attributes

– Execution time constraint (TIME)

– Main storage constraint (STOR)

– Virtual machine volatility (VIRT)

– Computer turn around time (TURN)

Intermediate Model

• The cost drivers are grouped into four categories

• Personnel attributes

– Analyst capability (ACAP)

– Application experience (AEXP)

– Programmer capability (PCAP)

– Virtual machine experience (VEXP)

– Programming Language Experience (LEXP)

• Project attributes

– Modern programming practices (MODP)

– Use of software tool (TOOL)

– Required development schedule (SCED)

Intermediate Model

• Each cost drive is rated for a given project environment.

• The rating uses a scale very low, low, nominal, high, very high, extra high

Ratings Cost drivers

Very low Low Nominal High Very High Extra High

Product Attributes

RELY 0.75 0.88 1.00 1.15 1.40

DATA 0.94 1.00 1.08 1.16

CPLX 0.70 0.85 1.00 1.15 1.30 1.65

Computer Attributes

TIME 1.00 1.11 1.30 1.66

STOR 1.00 1.06 1.21 1.56

VIRT 0.87 1.00 1.15 1.30

TURN 0.87 1.00 1.07 1.15

Personnel Attributes

ACAP 1.46 1.19 1.00 0.86 0.71

AEXP 1.29 1.13 1.00 0.91 0.82

PCAP 1.42 1.17 1.00 0.86 0.70

VEXP 1.21 1.10 1.00 0.90

LEXP 1.14 1.07 1.00 0.95

Project attributes

MODP .124 1.10 1.00 0.91 0.82

TOOL 1.24 1.10 1.00 0.91 0.83

SCED 1.23 1.08 1.00 1.04 1.10

Intermediate Model

• The multiplying factors for all cost drivers are multiplied to get the Effort Adjustment

Factor (EAF). Typically EAF range from 0.9 to 1.4

• The intermediate COCOMO equations take the form:

EAFKLOCaE ibi

idi EcD

Intermediate Model

Project ai bi ci di

Organic 3.2 1.05 2.5 0.38

Semi detached

3.0 1.12 2.5 0.35

Embedded

2.8 1.20 2.5 0.32

Detailed COCOMO Model

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

The detailed model introduces two more capabilities:

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

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

Development Phases

Software development is accomplished 4 successive phases

• Plans/Requirements: In this phase full product specification is generated and this consumes 6% to 8%of

the effort and 10% to 40% of the development time

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

development time

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

• Integration / Test: requires 16% to 34% of the nominal effort and can last from 18% to 34% of the

development time.

Principle of effort estimate• Size Equivalent:

– the software might be partly developed from software already existing, a full development is not always

required. In such cases, the parts of Design Document (DD%), Code (C%) and Integration (I%) to be

modified are estimated.

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

A = 0.4 DD + 0.3 C +0.3 I 3.1

The size equivalent is obtained by

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

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

Principle of effort estimate• Multipliers have been developed that can be applied to the total project effort, E, and the total project

development time, D in order to allocate effort and schedule components to each phase in the life cycle

phases, and the effort and schedule for each phase are assumed to be given in terms of the overall effort

and schedule by

• Ep

= p

E

• Dp

= p

D

Mode & code size Plan and Requirement

System Design

Detail Design

Module code & test

Integration & test

Life Cycle Phase Value p

Organic Small S = 2 0.06 0.16 0.26 0.42 0.16

Organic Medium S= 32 0.06 0.16 0.24 0.38 0.22

Semi det medium S= 32 0.07 0/17 0.25 0.33 0.25

Semi Det large S= 128 0.07 0.17 0.24 0.31 0.28

Embedded large S= 128 0.08 0.18 0.25 0.26 0.31

Embedded Extra. large S= 320

0.08 0.18 0.24 0.24 0.34

Mode & code size Plan and Requirement

System Design

Detail Design

Module code & test

Integration & test

Lifecycle Phase Value of p

Organic Small S = 2 0.10 0.19 0.24 0.39 0.18

Organic Medium S =32 0.12 0.19 0.21 0.34 0.26

Semi det medium S= 32 0.20 0.26 0.21 0.27 0.26

Semi Det large S= 128 0.22 0.27 0.19 0.25 0.29

Embedded large S= 128 0.36 0.36 0.18 0.18 0.28

Embedded Extra large S= 320

0.40 0.38 0.16 0.16 0.30

Principle of effort estimate

• COCOMO is highly calibrated model.

• It is easy to use and documented properly.

• It does not give proper importance to software requirements and specification phase.

Example

• A new project with estimated 400 KLOC embedded system has to be developed. Project manager has a

choice of hiring from two pools of developers: very highly capable with very little experience in the

programming language being used or developers of low quality but a lot of experience with the

programming language. What is the impact of hiring developers from one or the other pool.

Solution

• This is the case of embedded mode and model is intermediate COCOMO.

E= 2.8 (400)1.20 =3712 PM

• Case 1 Developers are very highly capable with very little experience in the programming being used

EAF = 0.70 * 1.14

(Programmer Capability (PCAP) 0.70)

(Programming Language Exp (LEXP) 1.14

• E1

= EAF *3712

• D = 2.5 (E1

) 0.32

ibi KLOCaE id

i EcD

Example

• Consider a project to develop a full screen editor. The major components identified are (1)

Screen edit (2) Command Language Interpreter (3) file input and output (4) cursor

movement (5) Screen Movement. The size of these are estimated to be 4K, 2K, 1K, 2K and

3K delivered source code lines. Use COCOMO model to determine:

• (a) Overall cost and schedule estimates

• (b) Cost and schedule estimates for different phases

Solution

• Size of five modules are:

• Screen edit = 4 KLOC

• Command Language Interpreter = 2 KLOC

• File input and output = 1 KLOC

• Cursor Movement = 2 KLOC

• Screen Movement = 3 KLOC

• Total =12 KLOC

Solution

Let us assume that the significant cost drivers are

– Required software reliability is high 1.15

– Product complexity is high 1.15

– Analyst capability is high 0.86

– Programming language experience is low 1.07

– All other drivers are nominal

EAF = 1.15 * 1.15 * 0.86 * 1.07 = 1.2169 EAFKLOCaE ibi

PME 91.522169.12.12.3 05.1

MD 29.1191.525.2 38.0

idi EcD

Using the following equations and referring phase wise cost and schedule estimates can be calculated

EE pp

DD pp

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

222

Learning Objectives (1)

• Items to consider when estimating cost

• Preparing a baseline budget

• Cumulating actual costs

• Determining the earned value of work performed

• Analyzing cost performance

• Forecasting project cost at completion

• Controlling project costs

• Managing cash flow

4

Project Cost Estimates (2)

• Cost planning starts with the proposal for the project.

• The cost section of a proposal may consist of elements such as the following:

– Labor. It might include the estimated hours and hourly rate for each person or classification.

– Materials.

– Subcontractors and consultants (if used).

– Equipment and facilities rental. If the contractor needs special equipment, tools, or facilities for the project.

– Travel. If it is required during the project.

• In addition to the above items, the contractor or project team may include an amount for contingencies.

• It is good practice to have the person who will be responsible for the costs associated with the work make the cost estimates.

• Historical data can be used as on the current project.

• Cost estimates should be realistic.

5

Project Budgeting (3)The project budgeting process involves two steps.

• First, the project cost estimate is allocated to the various work packages in the project work

breakdown structure.

• Second, the budget for each work package is distributed over the duration of the work

package..

6

Allocating the Total Budgeted Cost (TBC) (3A)• Allocating total project costs for the various elements to the appropriate work packages will establish a

total budgeted cost (TBC) for each work package.

• There are two approaches to establishing the TBC for each work package: top-down and bottom-up

Work Breakdown Structure with Allocated Budgets (3A)

6

Allocating the Total Budgeted Cost (TBC) (3A)

• When the budgets for all the work packages are summed, they cannot exceed the total project budgeted cost.

Network Diagram for the Packaging Machine Project

Work Breakdown Structure for the Packaging Machine Project

7

Developing the Cumulative Budgeted Cost (3B)

• Once a total budgeted cost has been established for each work package, the second step in the project budgeting process is to distribute each TBC over the duration of its work package.

• A cost is determined for each period, based on when the activities that make up the work package are scheduled to be performed.

• The cumulative budgeted cost (CBC) is the amount that was budgeted to accomplish the work that was scheduled to be performed up to that point in time.

Budgeted Cost by Period for the Packaging Machine Project (3B)

Cumulative Budgeted Cost Curve for the Packaging Machine

Project (3B)

7

Developing the Cumulative Budgeted Cost (3B)

• The CBC for the entire project or each work package provides a baseline against which

actual cost and work performance can be compared at any time during the project.

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

compared.

8

Determining Actual Cost (4)

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

A. Actual Cost

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

8

Determining Actual Cost (4B)B. Committed Cost

• In many projects, large dollar amounts are expended for materials or services (subcontractors, consultants)

that are used over a period of time longer than one cost reporting period.

• These committed costs need to be treated in a special way so that the system periodically assigns a portion of

their total cost to actual cost.

• Committed costs are also known as commitments or encumbered costs.

• Costs are committed when an item is ordered even though actual payment may take place at some later time.

8

Determining Actual Cost (4C)C. Comparing Actual Cost to Budgeted Cost

• As data are collected on actual cost, including portions of any committed cost, they need to be totaled by work package so that they can be

compared to the cumulative budgeted cost.

• Cumulative actual cost (CAC) should be calculated.

Actual Cost by Period for the Packaging Machine Project

Figure indicates that at the end of week 8, $68,000 has actually been expended on this project, although only $64,000 was budgeted

Cumulative Budgeted and Actual Cost for the Packaging Machine Project (4C)

9

Determining the Value of Work Performed (5)• Consider a project that involves painting ten similar rooms over ten days (one room per day) for a total

budgeted cost of $2,000. The budget is $200 per room.

• At of the end of day 5, you determine that $1,000 has actually been spent, but what if only three rooms have been painted?

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

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

• In many cases, the estimate is subjective.

9

Determining the Value of Work Performed (5)

• It’s important that the person estimating the percent complete not only assess how much

work has been performed but also consider what work remains to be done.

• For example, in the project involving painting ten rooms for $2,000, if three rooms were

completed, it’s safe to say that 30 percent of the work has been performed.

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

Calculate Cumulative Percent Complete by Period for the Packaging Machine Project (5)

Calculate Cumulative Earned Value by Period for the Packaging Machine Project (5)

Cumulative Budgeted, Actual, and Earned Value for the Packaging Machine Project (5)

10

Cost Performance Analysis Four Measures (6)The following four cost-related measures are used to analyze project cost performance:

TBC (total budgeted cost)

CBC (cumulative budgeted cost)

CAC (cumulative actual cost)

CEV (cumulative earned value)

• In the packaging machine project we see that:

– $64,000 was budgeted through the end of week 8.

– $68,000 was actually expended by the end of week 8.

– $54,000 was the earned value of work actually performed by the end of week 8.

111

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.

13

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

package.

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

• The first method assumes that the work to be performed on the remaining portion of the project or work package will be done

at the same rate of efficiency as the work performed so far.

Forecasted Cost at Completion =

F(Total budgeted cost, Cost performance index)

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

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

13

Cost Forcasting Three Methods (7 B)

• A second method for determining the forecasted cost at completion assumes that, regardless of the efficiency

rate the project or work package has experienced in the past, the work to be performed on the remaining portion

of the project or work package will be done according to budget.

• Forecasted cost at completion =

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

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

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

= $68,000 + $46,000

= $114,000

13

Cost Forcasting Three Methods (7C)

• A third method for determining the forecasted cost at completion is to re-estimate the costs for

all the remaining work to be performed and then add this re-estimate to the cumulative actual

cost.

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

14

Cost Control (8 A)

• The key to effective cost control is to analyze cost performance on a regular and timely basis.

• It’s crucial that cost variances and inefficiencies be identified early so that corrective action can be

taken before the situation gets worse.

• Cost control involves the following:

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

– Deciding what specific corrective action should be taken

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

14

Cost Control (8 B)

• When evaluating work packages that have a negative cost variance, you should

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

• Activities that will be performed in the near term. If you put off corrective actions until some point in the

distant future, the negative cost variance may deteriorate.

• Activities that have a large cost estimate. Taking corrective measures that reduce the cost of a $20,000

activity by 10 percent will have a larger impact than totally eliminating a $300 activity

14

Cost Control (8 C)

• There are various ways to reduce the costs of activities.

– One way is to substitute less expensive materials.

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

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

– Increasing productivity through improved methods or technology.

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

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

17

Managing Cash Flow

• It is important to manage the cash flow on a project.

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

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

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

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

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

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

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

18


• All costs associated resources can be stored. The software calculates the budget for

each work package and for the entire project.

• The software allows the user to define different rate structures for each resource and

when charges for those resources will be accrued.

• Cost tables and graphs are available to help analyze cost performance.

Risk Management

Projects can fail for a number of reasons and the risks are always high. While a project manager cannot eliminate risk, he/she can prevent or mitigate its impacts by using risk management.

“If You Don’t Actively Attack the Risks,

The Risks Will Actively Attack You.”

-Tom Gilb

Some definitions of risk

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

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

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

– It stems from the elements of uncertainty

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

Some definitions of risk

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

It relates to future:

Risk Planning involves speculating about future events. The future is inherently uncertain. Some things which seem obvious

when a particular project is over, for example that the costs were under-estimated or that a new technology was overly

difficult to use, might not have been so obvious during planning

It involves cause and effect

For example, a ‘cost over-run’ might be identifies as a risk, but does not say what caused it. Was it, for example, an

inaccurate estimate of effort, the use of untrained staff, or a poor specification?

A good definition of a specific risk identifies a situation (or hazard) and a particular type of negative outcome.

Boehm’s top 10 development risks

Risk Risk reduction techniques

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

Unrealistic time and cost estimates

Multiple estimation techniques; design to cost; incremental development; recording and analysis of past projects; standardization of methods

Developing the wrong software functions

Improved software evaluation; formal specification methods; user surveys; prototyping; early user manuals

Developing the wrong user interface

Prototyping; task analysis; user involvement

Boehm’s top ten risk - continued

Gold plating Requirements scrubbing, prototyping,design to cost

Late changes to requirements

Change control, incremental development

Shortfalls in externally supplied components

Benchmarking, inspections, formal specifications, contractual agreements, quality controls

Shortfalls in externally performed tasks

Quality assurance procedures, competitive design etc

Real time performance problems

Simulation, prototyping, tuning

Development technically too difficult

Technical analysis, cost-benefit analysis, prototyping , training

Categories of risk

Categories of risk

Actors : refers to all the people involved in the development of the application in question. These include the various development specialists, the

different user group, and managers with differing responsibilities.

A typical risk in this area is that high staff turnover leads to information of value to the project being lost. For example, if a software

developer builds a software component and then leaves before it has been fully tested, the team member taking over the component might

find that their lack of familiarity with the software makes diagnosis and correction of faults difficult.

Technology : Encompasses both the technology used to implement the application and that embedded in the delivered products.

Risk here could relate to the appropriateness of the technologies and to possible fault within them, especially if they are novel

Structure : describes the management structures and systems including those affecting planning and control. For example, the implementation

will need the users to carry our some tasks, but the responsibility for managing the users’ contribution to the project might not have been

clearly allocated.

Tasks means the work to be carried out. For example the complexity of the work might lead to delays because of the additional time required to

co-ordinate and integrate the large number of different elements.

Approaches to Risk Management

Approaches to Risk Management

Inactive Risk Management: We Simply neglect to consider risk issues at all. We just do not bother to address, or even concern ourselves with, the

possibility that things may not turn out as we intend. – BAD Risk management Approach

Reactive Risk Management: We attempt to post-mortem efforts to ameliorate the effects of risks that have materialized. This may involve crisis

management efforts to extricate an organization from a significant mess. More often, it is concerned with getting rid of bad or defective products,

often in the form of inspections, before they are delivered to consumers. This involves scarp and rework and therefore, increased production

expenses.

Interactive Risk Management: We are concerned with risk throughout each of the various lifecycles of various systems engineering efforts. This

means that we pay particular attention to such needs as configuration management and project controls to ensure that each phase of each lifecycle

is as risk free as possible in terms of the risk associated with the product of that particular phase

Proactive Risk Management: We plan and forecast risk potentials and then adopt systems management activities for technical directions that control,

to the extent possible, risk potentials across all organizational lifecycle processes. Ideally, we manage risk in a manner such that it is very unlikely

that any unnecessary risk actually occurs. In this way, we avoid the scrap and rework associated with an exclusively reactive approach to risk

management.

General Lifecycle Approaches to Risk Management

Risk Management

Ris

k P

lan

nin

g

Formulation

Analysis

Interpretation

Ris

k A

bat

emen

t

Detection

Diagnosis

Correction

Process of Risk Management

The process of risk management includes

– planning risk management : Used to determine the how of the risk management – how to plan and execute the risk management

activities of the given project

– Identifying and analyzing the risks :

– Preparing the response plan

– Monitoring the risk and

– Implementing the risk response, if the risk occurs

Process Used in Risk Management

Risk Management

Risk Identification

Qualitative Risk Analysis

Risk Monitoring and

Control

Risk Response Planning

Quantitative Risk Analysis

Planning Risk Management

Risk Management Planning is the process used to decide how the risk management activities for the project at hand will be

performed

The major goals for planning the risk management are threefold:

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

importance of the project to the organization

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

– Set up an agreed-upon basis for evaluating risks

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

– How to approach the risk management activities for this project

– How to plan the risk management activities

– How to execute the risk management activities

Risk identification

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

characteristics.

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

– Project Manager

– Project Team Members

– Risk Management team (if assigned)

– Subject matter experts from outside the project team

– Customers, end users, other project managers, stakeholders and risk management experts

Risk identification Tools and Techniques

Documentation Reviews:

• A structured review may be performed of project documentation, including plans, assumptions, prior project files and other information.

• The quality of the plans, as well as consistency between those plans and with the project requirements and assumptions can be indicators of risk in the project

Information Gathering Techniques:

• Brainstorming

• Delphi Technique

• Interviewing

• Root Cause Identification

• Strengths, Weaknesses, Opportunities and threats (SWOT) Analysis

Risk identification Techniques: 2. Information Gathering Technique : Brainstorming

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

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

brainstorming session

• Brainstorming is better performed under the guidance of a facilitator

• You can use the categories of risk to keep the session focussed on the issue

Risk identification Techniques: 2. Information Gathering Technique : Delphi Technique

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

• The Delphi technique is used to ensure that it is the quality of the information and the argument that are

important, not who is saying them.

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

project.

• The experts respond anonymously.

• The responses are compiled and circulated among the participating experts for further evaluation

without attaching a name to a response.

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

Risk identification Techniques: 2. Information Gathering Technique : Interviewing

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

identification.

• You interview the appropriate stakeholders and subject matter experts to gather

information that will help identify risks for the project at hand.

Risk identification Techniques: 2. Information Gathering Technique : Root Cause Identification

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

risk.

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

resulting from that cause.

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

• You can also look for risks at the opposite side of cause-that is impact.

Risk identification Techniques: 3. Information Gathering Technique : Checklist Analysis

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

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

• As a result, you can develop a risk identification checklist based on the information

gathered from a similar set of projects previously performed.

Risk identification Techniques: 4. Information Gathering Technique : Assumption Analysis

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

identify the risks

• Assumption analysis is the technique used to examine the validity of the assumptions and thereby to

identify the risk resulting from the inaccuracies, inconsistencies or incompleteness of each assumption.

• For example, assume that there is only one person in the organization who has a rare skill needed for

the project. An obvious assumption would be that the person will not quit the organization before

completing the assignment. The inaccuracy of this assumption amounts to the risk

Risk identification Techniques: 5. Information Gathering Technique : Diagramming Techniques

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

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

problems (effects)

Flowchart Diagram: A flowchart depicts how the elements of a system are related to each other and shows the logical flow of a

process. By examining the flowchart of a process, the risk management team can identify the points of potential problems in

the flowchart diagram.

Influence Diagram : An influence diagram is a graphical representations of situations that shows relationships among various

variables and outcomes, such as casual influences and time-ordering of events. By examining these diagrams, the risk

management team can recognize the potential problem areas and thereby identify risks.

The Output of Risk identification Risk Register

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

– List of identified Risks

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

– Updated Risk Categories: Risks categories were originally identified in the risk management planning process.

However, in the process of identifying risks new categories of risk may be discovered or existing risk may be modified.

– List of potential risk Responses

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

• Depending upon the project and experience of the risk management team, risk identification might lead directly to

the quantitative risk analysis and even to risk response planning

Analyzing Risk

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

– What are the odds that the risk will occur and

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

You get the answer by performing risk analysis:

– Qualitative Risk Analysis

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

– Quantitative Risk Analysis

• This is used to perform the numerical analysis to estimate the effect of each identified risk on the overall project

objectives and deliverables

Analyzing Risk : Qualitative Risk Analysis

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

risk analysis.

Techniques used for Qualitative Risk Analysis involve estimating probability and impact

• Risk Probability and Impact Assessment:

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

if it occurs

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

assessed

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

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

• To prioritize the risk, you need to look at both probability and impact


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 and impact matrix and what they mean depends upon the project and the organization

Remember– Higher value of a risk on the probability scale means – Greater

likelihood of risk occurrence– Higher value on the impact scale means- greater effect on the project

objectives


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


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.


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.


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


Decision Tree Analysis:

• This technique uses the decision tree diagram to choose from different available options, each option is represented by a branch of the

tree

• This technique is used when there are multiple possible outcomes with different threats or opportunities with certain probabilities

assigned to them

• EMV analysis is done along each branch, which helps to make a decision about which option to choose

Implementation Successful

Update or Build from scratch

Update

Cost=$50,000

Build from Scratch

Cost=$70,000

Implementation Failed

Implementation Successful

Implementation Failed

Probability=40%

Probability=10%

Impact=$2,00,000 Loss of Revenue

Impact=$2,00,000 Loss of Revenue

Example of Decision Tree Diagram


Option Initial Cost

Risk Cost Probability EMV for Risk Total Cost

Update $ 50,000 $ 2,00,000 40% 0.40*$2,00,000 = $80,000

50,000+80,000 = $1,30,000

Build From Scratch

$ 70,000 $ 2,00,000 10% 0.10*2,00,000 =$20,000

$70,000+$20,000 =$90,000

Though the initial cost for the update option is less than the initial cost for the build-from-scratch option, the decision will be made in favor of the build-from-scratch option because when you combine the initial cost with the EMV resulting from the probability of failure, the build-from-scratch option turns out to be a better deal

Analyzing Risk Output Quantitative Analysis Techniques

Probabilistic analysis of the project:

– This includes the estimates of the project schedule and cost with a confidence level attached to each estimate.

– Confidence level is expressed in percentage form such as 95% and it represents how certain you are about the estimate

Probability of achieving the project objectives:

– Factoring in the project risks, you can estimate the probabilities of meeting project objectives, such as cost and

schedule set forth by the current project plan. For example, the likelihood of completing the project within the

current budget plan of $2million is 70%

Prioritized list of risks: Risks are prioritized according to the threats they pose or the opportunities they offer.

Trends in the results: By repeating the analysis several times and by examining the results, you might recognize a trend for specific

risk. That trend might suggest further analysis or a specific risk response

Risk prioritization

A common problem with risk identification, particularly for the more anxious, is that a list of risks is potentially endless. Some way is,

therefore needed of distinguishing the more damaging and likely risks. This can be done by estimating the RISK EXPOSURE for

each risk using the FORMULA

Risk exposure (RE) = (potential damage) x (probability of occurrence)

Ideally

Potential damage: a money value e.g. a flood would cause £0.5 millions of damage

Probability 0.00 (absolutely no chance) to 1.00 (absolutely certain) e.g. 0.01 (one in hundred chance)

RE = £0.5m x 0.01 = £5,000

Crudely analogous to the amount needed for an insurance premium

Planning the Risk Response

Planning the Risk Response

Risk Response planning can start after risk identification, qualitative risk analysis, or quantitative risk analysis.

Central task in risk response planning is to develop actions and options to meet the following two goals

– Minimize threats to meeting project objectives

– Maximize opportunities

Three kinds of strategies available to handle three kinds of scenarios:

– Strategies to respond to negative risks when actions is required

– Strategies to respond to positives risks when actions is required

– Strategies that can be used to respond to both negative and positive risks when no action or a conditional action is taken

Planning the Risk Response: Response Strategies for Threats

Three strategies : Avoid, Transfer, Mitigate

• Avoid

– This can be accomplished in various ways, including

• Obtaining information and clarifying requirements for risks based on misunderstanding or miscommunication. This answers two question: Do we really

have this risk and if yes, how can we avoid it?

• Acquiring expertise for risks that exist due to a lack of expertise

• Isolating the project objectives from the risk whenever possible

• Relaxing the objective that is under threat, such as extending the project schedule

• Transfer

– Risk transfer means you shift the responsibility for responding to the risk (the ownership of the risk), the negative impact of the risk or both to another party.

Note that transferring the risk transfers the responsibility for risk management and does not necessarily eliminate the risk.

– Risk transfer almost always involves making payment of a risk premium to the party to which the risk has been transferred.

Planning the Risk Response: Response Strategies for Threats

Three strategies : Avoid, Transfer, Mitigate

• Mitigate

– Mitigation in general means taking action to reduce or prevent the impact of a disaster that is expected to occur.

– Risk Mitigation means reducing the probability of risk occurrence, reducing the impact of the risk if it does occur, or both

– A good mitigation strategy is to take actions early on to first reduce the probability of the risk happening, and then to plan for reducing its

impact if it does occur, rather than letting it occur and they trying to reduce the impact or repair the damage

• Following are some examples of mitigation:

– Adopting less complex process

– Conducting more tests on the product or service of the project

– Choosing a more stable supplier for the project supplies

– Designing redundancy into a system so that if one part fails, the redundant part takes over and the system keeps working

Risk reduction leverage

Risk Reduction action can be assessed by calculating the Risk Reduction Leverage. An RRL above 1.00 indicates that the

reduction in risk exposure achieved by a measure is greater than its cost.

Risk reduction leverage = (REbefore

- REafter

)/ (cost of risk reduction)

REbefore

is risk exposure before risk reduction e.g. 1% chance of a fire causing £200k damage

REafter

is risk exposure after risk reduction e.g. fire alarm costing £500 reduces probability of fire damage to 0.5%

RRL = (1% of £200k)-(0.5% of £200k)/£500 = 2

RRL > 1.00 therefore worth doing

Planning the Risk Response: Response Strategies for Opportunities

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

– Share

– Exploit

– Enhance

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

better equipped to capitalize on the opportunity.

• Exploit: Exploiting an opportunity means ensuring that the opportunity is realized – that is, the positive risk that presents the

opportunity does occur. This is accomplished by eliminating or minimizing the uncertainty associated with the risk occurrence.

For example, Provide better quality than planned to beat a competitor.

• Enhance: This strategy means increasing the size of the opportunity by increasing the probability, impact or both. You can

increase the probability by maximizing the key drivers of the positive risks or by strengthening the causes of the risks.

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

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

Acceptance: Acceptance of a risk means to let it be. Generally, it is not possible to take action against all the risks. Depending upon the

probabilities and impacts, some risks will simply be accepted: There are two kinds of acceptance:

– Passive Acceptance that requires no action

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

• Contingency: Generally speaking, contingency means a future event or condition that is possible but cannot be predicted with

certainty. So, your action will be contingent upon the condition- that is- it will be executed only if the condition happens.

– In risk management a contingent response, is a response that is executed only if certain predefined condition happens.

Output of the Risk Response Planning

1. Risk Register Updates : The appropriate risk responses planned and agreed upon by the risk management team are included in the risk

register. The responses to high and moderate risks are entered in details, while the low-priority risks can be put on a watch list for

monitoring.

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

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

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

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

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

– Budget and Schedule requirements to implement the planned responses, including the contingency reserve, which is the amount of funds, time or both needed in addition to the

estimates in order to meet the organization’s and stakeholder’ risk tolerances and thresholds

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

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

3. Project management Plan Updates

Risk Response Control

• Risk response control involves executing the risk management plan in order to respond to

risk events over the course of the project.

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

• It is important to understand that even the most thorough and comprehensive analysis

cannot identify all risks and probabilities correctly- control and iteration are required.

Tools and Techniques for Risk Response Control

– Workarounds. Workarounds are unplanned responses to negative risk events. Workarounds are

unplanned only in the sense that the response was not defined in advance of the risk event occurring.

– Additional risk response development. If the risk event was not anticipated, or the effect is greater than

expected, the planned response may not be adequate, and it will be necessary to repeat the response

development process and perhaps the risk quantification process as well.

Output From Risk Response Control

Corrective action. Corrective action consists primarily of performing the planned risk response

(e.g., implementing contingency plans or workarounds).

Updates to risk management plan. As anticipated risk events occur or fail to occur, and as

actual risk event effects are evaluated, estimates of probabilities and value, as well as other

aspects of the risk management plan, should be updated.

Monitoring and Controlling the Projects

Introduction

Executing a project means

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

baseline, a scope baseline, and a cost baseline

• Monitoring : Watching the course

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

• Monitoring includes

– measuring the project performance,

– collecting and distributing information about the project performance and

– evaluating the performance information to see the trends.

• Continuous monitoring helps the project management team identify the areas that need to be controlled

closely by, for example, taking corrective or preventive actions

Monitoring and Controlling

Some of the major tasks involved in monitoring and controlling the project are actions:

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

scope

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

information among the stakeholders

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

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

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

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

• Monitoring and controlling changes and monitoring the implementation of approved changes

Monitoring and Controlling

A project is monitored and controlled using the monitor and control project work process, which is a high-level process that is

performed by executing more specific processes, such as cost control, schedule control and scope control

Monitoring and Control Project Work

Integrated Change Control

Cost Control

Manage Project

Plan

Quality Control

Risk Monitoring

and Controlling

Schedule Control

Scope Control

Fig. : Some Processes in the Monitoring and Controlling Process Group

Integrated Change Control Process

The integrated change control process is used to manage changes to the project from project initiation through project closure.

A project rarely runs exactly according to the project management plan, and therefore changes will inevitably appear.

The changes request can come from:

– Evaluating the project performance to bring the project in line with the project management plan or

– They can come from other sources, such as the stakeholders

• Regardless of where changes originate from, all changes need to be managed (monitored and control) which includes:

– getting the changes rejected or approved,

– seeing the approved changes implemented and

– changing the affected plans accordingly

Integrated Change Control Process

Managing change includes the following:

– Identifying a change that has occurred and receiving a change request

– Getting the requested changes approved or rejected. Depending on the project and the performing organization, the authority to determine

whether a change is eventually rejected or approved might lie with the project manager, a customer, a sponsor, or a committee.

• Monitoring and controlling the flow of approved changes involves:

– Making sure they are implemented

– Maintaining the integrity of the project baseline (cost, schedule and scope) by updating it to incorporate the approved changes

– Coordinating changes and their impact across the project and updating the affected documentation. For example, an approved schedule

change might impact cost, quality risk and staffing.

• Controlling the Project Quality- e.g. Through defect repairs and recommended corrective and preventive actions

• Making sure that only the approved changes are implemented

Integrated Change Control ProcessInput Tools and Techniques Output

Change request Recommended Items:

Corrective Actions Preventive Actions Defect Repairs

Project Management Plan Work Performance

Information

Project Management Methodology

Project Management Information Systems

Expert Judgment

Approved and Rejected Items:

Change Request Defect Repairs Corrective Actions

and Preventive Actions

Validated Items: Defect Repairs

Updates Project

Management Plan Project Scope

Statement

Controlling QualityControlling quality involves monitoring specific results to determine whether they comply with the planned quality

standards, which include project processes and product goals and controlling the results by taking actions to

eliminate unsatisfactory performance

Controlling Quality involves:

– Monitor specific project results, such as cost performance and schedule performance, to determine whether they comply with

the planned quality standards, which include project processes and product goals

– Identify ways to eliminate the causes of unsatisfactory performance

Controlling Quality

Input Tools and Techniques Output Output of quality

planning: Quality Management

Plan Quality Metrics Quality Checklist

Output of direct and manage project execution

Approved change request Organizational Process

Assets

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

diagram Statistical Sampling Inspection Defect Repair Review

Quality Control Measurement

Recommended Items: Corrective Actions Preventive Actions Defect Repairs and Change of request

Validated Items: Deliverables and

defect repair Updates: Project management

plan Quality baseline

and Organizational

process assets

Seven Basic Tools of Quality1.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 Quality5. 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 Quality6. Control Charts :Control charts are used to monitor whether the variance of a specified variable is within acceptable limits dictated by quality control.

A variance is a measurable deviation in the value of a project variable, such as cost from a know baseline or expected value. This

is a way to monitor the deviations and determine whether the corresponding variable is in or out of control. The values are taken

at different times to measure the behaviour of a variable over time.

The mean value in the control chart represents the expected value, and predetermined spread from the mean value (usually ±3) is

used to define the limits within which an acceptable value can fall

Example : Assume that a manufacturer produces 100 units of a product each day and it is expected that 95 out of 100 units should have no defect – that

is, the expected number of defective units is equal to 5. The control limits are set to ±3. In other words, 95 units out of 100 must be

correct, give or take three. That puts the lower limit at 92 and the upper limit at 98. Crossing the lower limits is not acceptable to

the customer and crossing the upper litmus might require an unjustifiable cost.

An Example of a Control Chart

92

95

99

Lower control limit

Mean

Upper control limit

Time

Seven Basic Tools of Quality7. Cause and Effect Diagram :A cause and effect diagram is used to explore all the potential causes (inputs) that result in a single effect (output), such

as a problem or a defect. This type of diagram is the brainchild of Kaoru Ishikawa, who pioneered quality management process in the Kawasaki

Shipyards, and therefore these diagrams are also called Ishikawa Diagrams. Due to the shape of the diagram, it is also called as fishbone

diagram. To construct and use cause and effect diagrams effectively, perform the following simple steps:

a) Identify the Problem: Write down the problem in the box drawn on the right side of a sheet of paper. This represents the head of the fish.

Starting from the box, draw a horizontal line across the paper. This represents the spine of the fish

b) Identify the possible areas of causes: Identify the areas or factors from where the potential causes of the problem might come. Environment,

people, materials, measurements and methods are some examples of areas (factors) of causes. For each factor relevant to the problem under

study, draw a line off the spine and label it with the name of the factor. These lines represent the fish bones.

c) Identify the possible causes: For ach factor, identify possible causes. Represent each possible cause with a line coming off the bone that

represent the corresponding factor.

d) Analyze the diagram: Analyzing the diagram includes narrowing down the most likely causes and investigating them further

An example of cause and effect diagram

Delay in Web Site

Release

Time

People

Shutdown Periods

Efficiency of Night Shifts

Hiring

Too many Commitments

Shutdown Periods

Methods

Environment

Need

Accuracy

Testing Environment

Development Environment

Efficiency

Cause and Effect Diagram :A cause and effect diagram is a structured way to think through all possible causes of a problem. You can use these diagram to carry out a thorough analysis of a problematic situation

Output of Quality ControlThe 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


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


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


Fig. The process to close the project

Close Project

Contract Closure

1. Establish procedures for administrative closure and contract closure

2. Implement Administrative Closure

1. Implement Contract Closure

Integrated Change Control ProcessInput Tools and Techniques Output

Project Management Plan Deliverables Work Performance

Information Contract Documentation Organizational Process

Assets Enterprise Environmental

Factors

Project Management Methodology

Project Management Information Systems

Expert Judgment

Administrative closure procedure

Formal Acceptance for the final product

Updates to organizational process assets

Contract closure procedrue

Output of the Project Closure

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

– Closing procedures

– Acceptance of the project deliverables by the customer and

– Archival of project-related documents


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


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 ClosureUpdates 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 ClosureA 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 projectPart 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 ResourcesFor 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

Software project management

Business

Transcript of Software project management