Date post: | 03-Nov-2014 |
Category: |
Documents |
Upload: | sheel-sindhu-manohar |
View: | 254 times |
Download: | 0 times |
Project Management
August 2007
Syllabus
Course Contents:
Introduction to Project Management: Project Management Life Cycle
Software Project Planning, Project Activities and Work Breakdown Structure
Project Management Plan, Project Scheduling and Tracking Techniques
Project Economics: Project Costing, Project Estimation Techniques, Automated Estimation Tools
Risk Analysis and Management, Risk Mitigation and Management, Software Metrics and Project Management
Project Control and Closure, Project Management Issues with regard to New Technologies
Suggested Readings:
1. Bob Hughes and Mike Cotterell, “Software Project Management”, Fourth Edition 2006, TMH
2. Pankaj Jalote, “Software Project Management in Practice”, 2002, Pearson Education Asia. 3. Software Project Management- A unified Approach, Walker Royce, Pearson Education3. 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 Characteristics1. 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 upA 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 lease one project objective
The Project Management team has a professional responsibility to its stakeholders including customers, the performing organization and the public
Activities covered by project management
Feasibility studyIs project technically feasible and worthwhile from a
business point of view?Planning
Only done if project is feasibleExecution
Implement plan, but plan may be changed as we go along
Project Management Knowledge Areas
Project Management Knowledge Areas
Project Integration Management, describes the processes and activities that integrate the various elements of project management, which are identified, defined, combined, unified and coordinated within the Project Management Process Groups. It consists of the Develop Project Charter, Develop Preliminary Project Scope Statement, Develop Project Management Plan, Direct and Manage Project Execution, Monitor and Control Project Work, Integrated Change Control, and Close Project management processes.
Project Scope Management, describes the processes involved in ascertaining that the project includes all the work required, and only the work required, to complete the project successfully. It consists of the Scope Planning, Scope Definition, Create WBS, Scope Verification, and Scope Control project management processes.
Project Time Management, describes the processes concerning the timely completion of the project. It consists of the Activity Definition, Activity Sequencing, Activity Resource Estimating, Activity Duration Estimating, Schedule Development, and Schedule Control project management processes.
Project Management Knowledge Areas
Project Cost Management, describes the processes involved in planning, estimating, budgeting, and controlling costs so that the project is completed within the approved budget. It consists of the Cost Estimating, Cost Budgeting, and Cost Control project management processes.
Project Quality Management, describes the processes involved in assuring that the project will satisfy the objectives for which it was undertaken. It consists of the Quality Planning, Perform Quality Assurance, and Perform Quality Control project management processes.
Project Human Resource Management, describes the processes that organize and manage the project team. It consists of the Human Resource Planning, Acquire Project Team, Develop Project Team, and Manage Project Team project management processes.
Project Communications Management, describes the processes concerning the timely and appropriate generation, collection, dissemination, storage and ultimate disposition of project information. It consists of the Communications Planning, Information Distribution, Performance Reporting, and Manage Stakeholders project management processes
Project Management Knowledge Areas
Project Risk Management, describes the processes concerned with conducting risk management on a project. It consists of the Risk Management Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, and Risk Monitoring and Control project management processes.
Project Procurement Management, describes the processes that purchase or acquire products, services or results, as well as contract management processes. It consists of the Plan Purchases and Acquisitions, Plan Contracting, Request Seller Responses, Select Sellers, Contract Administration, and Contract Closure project management processes.
Areas of Expertise Needed by the Project Team
Application Area Knowledge, Standards and 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
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 SolutionSubmission of proposal(s) to the customer by one or more individuals or organizationsAfter 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 ProjectWhen a project is completed, certain close-out activities need to be
performed:– Confirming that all deliverables have been provided to and
accepted by the customer– All payments have been collected– Evaluating performance of the project in order to learn what
could be improved if a similar project were to be carried out in the future
– Obtain feedback from the customer to determine the level of the customer’s satisfaction and whether the project met the customer’s expectations.
– Obtain the feedback from the project team in the form of recommendations for improving performance of projects in the future
The Project Management Process
Project Management involves a process of first establishing a plan and
then implementing that plan to accomplish the project objective.The Planning effort includes the following steps:
– Clearly define the project objective– Divide and subdivide the project scope into major “pieces” or work
packages by preparing work breakdown structure (WBS)– Define the specific activities that need to be performed for each work
package in order to accomplish the project objective– Graphically portray the activities in the form of a network diagram.
This diagram shows the necessary sequence and interdependencies of activities to achieve the project objectives.
– Make a time estimate for how long it will take to complete each activity.
– Make a cost estimate for each activity– Calculate a project schedule and budget to determine whether the
project can be completed within the required time, with the allotted funds and with the available resources.
Project Life Cycle
Phase 1 : Needs Identification
Need Identification
Need identification is the initial phase of the project life cycle. The customer identifies a need, a problem or an opportunity for a better way of doing something and therefore sees some benefit to undertaking a project that will result in an improvement or advantage over the existing condition
This phase encompasses : Identifying needs and selecting projects
Developing a request for proposal
The proposal solicitation process
Need Identification : Project Selection
Project Selection involves :1. Evaluating various needs or opportunities
2. Deciding which of these should move forward as a project to be implemented
3. Benefits and consequences need to be considered and evaluated. They could be quantitative and qualitative, tangible and intangible
The Steps in project Selection are :– Develop a set of criteria against which the opportunity will be
evaluated
– List assumptions that will be used as the basis for each opportunity
– Gather data and information for each opportunity to help ensure an intelligent decision regarding project selection
• Preliminary Financial Estimates associated with each opportunity• Gather information about each stakeholder
– Evaluate the opportunity against the criteria
Need Identification : Request for Proposal
The purpose of preparing a request for proposal is to state, comprehensively and in details, what is required from the customer’s point of view, to address the identified need
A good RFP allows contractors or a project team to understand what the customer expects so that they can prepare a thorough proposal that will satisfy the customer’s requirement at a realistic price
Need Identification : Request for Proposal
The purpose of preparing a request for proposal is to state, comprehensively and in details, what is required from the customer’s point of view, to address the identified need
A good RFP allows contractors or a project team to understand what the customer expects so that they can prepare a thorough proposal that will satisfy the customer’s requirement at a realistic price
Need Identification : Request for Proposal - Guidelines
1. An RFP must provide a statement of work (SOW)A SOW deals with the scope of the project, outlining the tasks or work elements the customer wants the contractor or project team to perform.
2. The RFP must include the customer requirements which define specifications and attributes
3. The RFP should state what deliverable the customer expects the contractor or project team to provide
4. The RFP should list any customer-supplied items.5. The RFP might state the approvals required by the customer6. Some RFPs mention the type of contract the customer intends to
use7. An RFP might state the payment terms the customer intends to use 8. The RFP should state the reqwuired schedule for completion of the
project9. The RFP should provide instructions for the format and content of
the contractor proposals10. 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 include1. 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?
RiskIs there a risk that the project will be unsuccessful – technically or
financially?
MissionIs the proposed project consistent with the contractor’s bhusiness mission
Extension of CapabilitiesWould the proposed project provide the contractor with an opportunity to
extend and enhance its capabilities
Reputation– Has the contractor successfully completed projects for the same
customer in the past or were the problems that left the customer dissatisfied?
– Has the contractor unsuccessfully bid on RFPs from the customer in the past?
Proposed Solution : Bid / No Bid Decision
Customer Funds – Does the customer really have funds available to go forward with the
project? Or is the customer on a “fishing expedition” – issuing an RFP although unsure whether the project will ever be funded? A customer may issue an RFP with the best of intentions but do so prematurely, anticipating that the Board of Directors will approve funding. However, if the company is having financial difficulties, the board may decide to postpone the project indefinitely, even after proposals have been received from interested contractors
Proposal Resource– Are appropriate resources available to prepare a quality proposal? It is
not enough for a contractor to just prepare a proposal– It is imperative that the proposal be of sufficient quality to have a good
chance of winning. To prepare a quality proposals, a contractor must have the appropriate people – that is, resource – to work on it.
Project ResourcesAre appropriate resource available to perform the project if the contractor
is selected as the winner? Contractors need to be sure that the appropriate individuals within their organizations will be available to work on the project.
9
Developing a Winning Proposal• A selling document – not a technical report• Convince the customer that you are the best one to solve the problem. That
is the contractor– Understands what the customer is looking for– Can carry out the proposed project– Will provide the greatest value to the customer– Is the best contractor to solve the problem– Will capitalize on its successful experience with previous related projects– Will do the work professionally– Will achieve the intended results– Will complete the project within budge and on schedule– Will satisfy the customer
• Highlight the unique factors that differentiate you from competing contractors
• Emphasize the benefits to the customer• Write in a simple, concise manner• Address requirements as laid out in the RFP• Be realistic in scope, cost, and schedule
9
Developing a Winning Proposal• A selling document – not a technical report• Convince the customer that you are the best one to solve the problem. That
is the contractor– Understands what the customer is looking for– Can carry out the proposed project– Will provide the greatest value to the customer– Is the best contractor to solve the problem– Will capitalize on its successful experience with previous related projects– Will do the work professionally– Will achieve the intended results– Will complete the project within budge and on schedule– Will satisfy the customer
• Highlight the unique factors that differentiate you from competing contractors
• Emphasize the benefits to the customer• Write in a simple, concise manner• Address requirements as laid out in the RFP• Be realistic in scope, cost, and schedule
10
Proposal Preparation
• Can be a straightforward task performed by one person or a resource-intensive effort requiring a team
• May designate a proposal manager • Schedule must allow time for review and approval by
management • Can be a few pages or hundreds of pages• Customers do not pay contractors to prepare
proposals
11
Proposal Contents
Proposals are organized into three sections:
• Technical Section
• Management Section
• Cost Section
11
Proposal Contents : Technical Section
The objective of the technical section of the contractor proposal is to convince the customer that the contractor understands the need or problem and can provide the least risky and most beneficial solution.
The elements of the Technical Section are
1. understanding of the problem
– Contractor thoroughly understands the problem to be solved
– Establish the basis for the solution proposed later in the technical section
2. proposed approach or solution
– A description of how the contractor would collect, analyze and evaluate data and information about the problem
– Methods that would be used by the contractor to evaluate alternative solutions or further develop the proposed solution to the problem
– The rationale for the proposed approach or solution. This rationale could be based on experiments previously conducted by the contractor, the contractor's experience in solving similar problems or a unique patented technology the contractor would use to solve the problem
– Confirmation that the proposed solution or approach would meet each of the physical, operational and performance requirement stated in the customer's RFP
11
Proposal Contents : Technical Section
3. benefits to the customer• The contractor should state how the proposed solution or approach would
benefit the customer.
• Benefits could be quantitative or qualitative and could include cost savings; reduced processing time; reduced inventory; better customer service; less scrap, rejects or errors, ; improved safety conditions; more timely information and reduced maintenance
• This portion of the proposal should help convince the customer of the value of the proposed approach compared with proposals from competing contractors
12
Proposal Contents : Management Section
Objective
to convince the customer that the contractor can do the proposed work and achieve the intended results
The Management Section should contain the following elements:
– description of work tasks
– deliverables
– project schedule
– project organization
– related experience
– equipment and facilities
13
Proposal Contents : Cost Section
The objective of the cost section of the contractor proposal is to convince the customer that the contractor’s price for the proposed project is realistic and reasonable.
The cost section usually consist of• Labor :
– estimated costs of the various classifications of people who are expected to work on the project.
– It might include the estimate hours and hourly rate for each person or classification– The estimates should be realistic
• Materials• subcontractors and consultants• equipment and facilities rental• travel• documentation• Overhead
– Contractor will add a percentage to costs in items above to cover their normal overhead – the indirect costs of doing business, such as insurance, depreciation, accounting, general management, marketing and human resources
• escalation• contingency or management reserve• fee or profit
14
Pricing Considerations
Be careful not to overprice or underprice the proposed project
Consider:• reliability of the cost estimates
– Does the total cost of the proposed project is complete and accurate?– Costs should be based on a recent similar project or, in the case of materials cost
estimates, on current price lists, catalogues or quotations.• Risk
– If the project involves an endeavor that has not been undertaken before, such as R&D, it may be necessary to include a large amount or contingency or management reserve funds.
• value of the project to the contractor • customer’s budget
– Pre-RFP marketing may help to know the customer budget• Competition
15
Proposal Submission and Follow-Up
• Submit proposals on time
• Hand deliver expensive proposals or send 2 sets by different express mail services, if necessary
• Continue to be proactive even after submission
16
Customer Evaluation of Proposals
• Some look at the prices and select only from the three lowest-priced proposals
• Some screen out prices above budget or whose technical section doesn’t meet all the requirements
• Some create a proposal review team that uses a scorecard
• May submit a best and final offer (BAFO)
17
Customer Evaluation of Proposals (Cont.)
• Criteria that might be used in evaluating:– compliance with SOW– understanding of the problem or need– soundness of the proposed approach – contractor’s experience and past success – experience of key individuals– management capability– realism of the schedule– price – reasonableness, realism, and completeness
After selecting a contractor, a contract must be signed between the customer and the contractor
A contract is:
• A vehicle for establishing customer-contractor communications and arriving at a mutual understanding and clear expectations
• An agreement between the contractor, who agrees to provide a product or service, and the customer, who agrees to pay
• Must clearly spell out the deliverables
• Two types of contracts: fixed price and cost reimbursement
18
Types of Contracts
19
Types of Contracts (Cont.)
Fixed-price contract
• Price remains fixed unless the customer and contractor agree
• Provides low risk for the customer
• Provides high risk for the contractor
• Is most appropriate for projects that are well defined and entail little risk
20
Types of Contracts (Cont.)
Cost-reimbursement contract
• Provides high risk for the customer
• Provides low risk for the contractor
• Is most appropriate for projects that involve risk
• Customer usually requires that the contractor regularly compare actual expenditures with the proposed budget and reforecast cost-at-completion
21
Contract Provisions
Misrepresentation of costs - states that it is illegal for the contractor to overstate the hours or costs expended on the project.Notice of cost overruns or schedule delays - outlines the circumstances under which the contractor must notify the customer any schedule delays.Approval of subcontractor - indicates when the contractor needs to obtain approval before hiring a subcontractor.Customer-furnished equipment or information - lists the items that the customer will provide to the contractor throughout the project and the dates by which the customer will make these items available. Patents - covers ownership of patents that may result from conducting the project.Disclosure of proprietary information - prohibits one party from disclosing project confidential information, technologies, or processes.Termination - states the conditions under which the customer can terminate the contract, such as nonperformance by the contractor
21
Contract Provisions
• Terms of payment - addresses the basis on which the customer will make payments to the contractor.
• Bonus/penalty payments - some contracts have a bonus provision, whereby the customer will pay the contractor a bonus if the project is completed ahead of schedule or exceeds other customer performance requirements. On the other hand, some contracts include a penalty provision, whereby the customer can reduce the final payment to the contractor if the project is not completed on schedule or if performance requirements are not met.
• Changes. Covers the procedure for proposing, approving, and implementing changes to the project scope or schedule.
Project Management Processes
Project Management Process
• Project management is an integrative endeavor — an action, or failure to take action, in one area will usually affect other areas.
• The interactions may be straightforward and well-understood, or they may be subtle and uncertain.
• For example, a scope change will almost always affect project cost, but it may or may not affect team morale or product quality.
Project Management Process
• Projects are composed of processes. A process is "a series of actions bringing about a result"
• Project management processes can be organized into five following groups
(Arrows represent flow of documents and documentable items)
Project Management Process
Executing
Processes
Level
of
Activity
Phase
Start
Time Phase
Finish
Planning
Processes
Closing
Processes
Initiating
Processes
Overlap of Process Groups in a Phase
1. Initiating a process
• Initiation – Committing the organization to begin the next phase of the project
2. Planning a Processes
• Planning is of major importance to a project because the project involves doing something which has not been done before.
• As a result, there are relatively more processes in this section. However, the number of processes does not mean that project management is primarily planning
• The amount of planning performed should be commensurate with the scope of the project and the usefulness of the information developed.
• The relationships among the project planning processes are shown in Figure on next slide
• These processes are subject to frequent iterations prior to completing the plan. For example, if the initial completion date is unacceptable, project resources, cost, or even scope may need to be redefined.
• In addition, planning is not an exact science—two different teams could generate very different plans for the same project.
2. Planning process : Core processes
• Some planning processes have clear dependencies that require them to be performed in essentially the same order on most projects. For example, activities must be defined before they can be scheduled or costed. These core planning processes may be iterated several times during any one phase of a project. They include:
• Scope Planning — developing a written scope statement as the basis for future project decisions.
• Scope Definition — subdividing the major project deliverables into smaller, more manageable components.
• Activity Definition - identifying the specific activities that must be per formed to produce the various project deliverables
• Activity Sequencing —identifying an documenting interactivity dependencies.
• Activity Duration Estimating — estimating the number of work periods which will be needed to complete individual activities
2. Planning process : Core processes
• Schedule Development —analyzing activity sequences, activity durations, and resource requirements to create the project schedule.
• Resource Planning —determining what resources (people, equipment, 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 if
they 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
Exercise
Draw a network diagram representing the following logic: As the project starts, activities A and B can be performed concurrently. When A is finished, activities C and D can start. When B is finished, activities E and F can start. When activities D and E are finished, activity G can start. The project is complete when activities C, F, and G are finished. Use both the activity-in-the-box and the activity-on-the-arrow formats .
A C
D
B E G
F
Start Finish
21
Exercise
Activity Immediate Predecessor
1. Problem Definition —
2. Study Current System 1
3. Define User Requirements 1
4. Logical System Design 3
5. Physical System Design 2
6. System Development 4, 5
7. System Testing 6
8. Convert Database 4, 5
9. System Conversion 7, 8
1 2 5 6 7 9
3 4 8
21
Exercise
Draw a network diagram representing the following logic:
• As the project starts, activities A and B can be performed concurrently. When A is finished, activities C and D can start. When B is finished, activities E and F can start. When activities D and E are finished, activity G can start. The project is complete when activities C, F, and G are finished. Use both the activity-in-the-box and the activity-on-the-arrow formats .
21
Information System, Defined
• An information system (IS) is a computer-based system that accepts data as input, processes the data, and produces useful information for users.
22
Planning for Information Systems Development
• The systems development life cycle (SDLC) is used to help plan, execute and control IS development projects.
• Many people view the SDLC as a classic problem-solving approach.
23
Steps of the SDLC
• Problem definition• System analysis• System design• System development• System testing• System implementation
24
Project Management Software
You are advised to prepare the following
• WBS
• Responsibility Matrix
• Gant Chart
• Network Diagram
Scheduling
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. • he activities that have this same value of total slack make up the
path 1–2–3–4–6–9–11–12–13. • To eliminate the –8 days of slack, the estimated durations of one or
more activities on this critical path need to be reduced. • Suppose we reduce the estimated duration of “Mail Questionnaire &
Get Responses” from 65 days to 55 days. The total slack changes from –8 days to +2 days.
• Those paths with positive values of total slack are sometimes referred to as noncritical paths, while those paths with zero or negative values of total slack are referred to as critical paths.
• n this case the longest path is often referred to as the most critical path.
16
Free Slack
• Free slack is the amount of time a particular activity can be delayed without delaying the earliest start time of its immediately succeeding activities.
• It is the relative difference between the amounts of total slack for activities entering into the same activity.
• It is always a positive value • In the network diagram (Figure on Next slide), there are
three instances where a particular activity has more than one activity entering into it:– Activity 9, “Mail Questionnaire & Get Responses,” has activities 5
and 6 entering into it.– Activity 10, “Test Software,” has activities 7 and 8 entering into it.– Activity 11, “Input Response Data,” has activities 9 and 10
entering into it.
17
Free Slack
16
Free Slack
• The values of total slack for activities 5 and 6 are 0 and –8 days, respectively.
• The lesser of these two values is –8 days for activity 6. • The free slack for activity 5 is the relative difference
between its total slack, 0, and –8. This relative difference is 8 days: 0 – (–8) = 8 days.
Scheduling-PERT
20
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
Pro
ject C
on
trol P
rocess
5
Project Control Process
• The key to effective project control is to measure actual progress and compare it to planned progress on a timely and regular basis and to take necessary corrective action immediately.
• Establish a regular reporting period. • During each reporting period, collect:
– data on actual performance– information on any changes to project scope, schedule and budget.
• If changes are incorporated, a new plan must be established.
Project management is a proactive approach to controlling a project, to ensure that the project objective is achieved even when things don't go according to plan
6
Effects of Actual Schedule Performance• Throughout a project, some activities will be completed on time, some will be
finished ahead of schedule, and others will be finished later than the schedule
• Actual Progress – whether faster or slower than planned – will have an effect on the schedule of the remaining uncompleted activities of the project
• Actual finish times (AFT) of completed activities will determine the earliest start and earliest finish times for the remaining activities.
7
Incorporating Project Changes into the Schedule
• Changes might be initiated by the customer or the project team, or they might be the result of an unanticipated occurrence.
• The degree of impact may depend on when the changes are requested.
• If they’re requested early in the project, they may have less impact on cost and schedule
• When the customer requests a change, additional costs might need to be charged.
Network Diagram for Consumer Market Study Project,Showing the Critical Path
Revised Schedule for Consumer Market Study Project
8
Updating the Project Schedule
• Once data have been collected on the actual finish times of completed activities and the effects of any project changes, an updated project schedule can be calculated based on the actual finish times of completed activities.
• Changes in the Network diagram studied in last class– Completed Activities
Activity 1: “Identify Target Consumers” actually finished on day 2
Activity 2: “Develop Draft Questionnaire” actually finished on day 11
Activity 3 : “Pilot-Test Questionnaire” actually finished on day 30
– Project Changes• It was discovered that the database to be used to prepare the mailing labels
was not up to date. A new database needs to be purchased before the mailing labels can be prepared. This new database was ordered on day 23. It will take 21 days to get it from the supplier
• A preliminary review of comments from the pilot test of the questionnaire indicates that substantial revisions to the questionnaire are required. Therefore, the duration estimate for activity 4 needs to be increased from 5 days to 15 days
Network Diagram for Consumer Market Study Project, Incorporating Actual Progress and Changes
Updated Schedule for Consumer Market Study Project Consumer Market Study Project
9
Approaches to Schedule Control Four Steps
Schedule control involves four steps:– Analyzing the schedule to determine which areas may need
corrective action– Deciding what specific corrective actions should be taken– Revising the plan to incorporate the chosen corrective actions– Recalculating the schedule to evaluate the effects of the planned
corrective actions
• If the planned corrective actions do not result in an acceptable schedule, these steps need to be repeated
10
Approaches to Schedule Control (Cont.)
• A change in the estimated duration of any activity on that path will cause a corresponding change in the slack for that path.
• When analyzing a path of activities that has negative slack, you should focus on two kinds of activities:– Activities that are near term (that is, in progress or to
be started in the immediate future).– Activities that have long estimated durations
11
Reducing the Estimated Durations
There are various approaches to reducing the estimated durations of activities. – One obvious way is to apply more resources to speed up an
activity. Sometimes, however, adding people to an activity may in fact result in the activity’s taking longer.
– Another approach is to assign a person with greater expertise or more experience to perform or help with the activity.
– Reducing the scope or requirements for an activity is another way to reduce its estimated duration.
– In an extreme case, it may be decided to totally eliminate some activities.
– Increasing productivity through improved methods or technology is yet another approach.
12
Approaches to Schedule Control (Cont.)
• In most cases, eliminating negative slack by reducing durations of activities will involve a trade-off in the form of an increase in costs or a reduction in scope.
• Some contracts include a bonus provision, whereby the customer will pay the contractor a bonus if the project is completed ahead of schedule.
• Conversely, some contracts include a penalty provision, whereby the customer can reduce final payment to the contractor if the project is not completed on time.
• The key to effective schedule control is to aggressively address any paths with negative or deteriorating slack values as soon as they are identified.
13
Schedule Control for Information Systems Development
• Controlling the schedule for the development of an information system is a challenge.
• Among the changes that commonly become necessary during IS development projects are the following:– Changes to input screens– Changes to reports– Changes to on-line queries– Changes to database structures– Changes to software processing routines– Changes to processing speeds– Changes to storage capacities– Changes to business processes– Changes to software resulting from hardware upgrades or,
conversely, hardware upgrades resulting from the availability of more powerful software
14
Project Management Software
• The software allows you to perform various control functions.
• The percent complete for each task can be entered.
• Changes to the duration estimates can be entered.
• The software will automatically revise the project schedule and the corresponding network diagrams.
Resource Considerations
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
Planned Resource Utilization Resource Profile for Painters : Uneven Utilization of Painters
5
Planned Resource Utilization
• Sometimes it’s preferable to have a more uniform, or level, application of resources.
• Resource utilization based on each activity’s earliest start time are said to be based on an as-soon-as-possible (ASAP) schedule.
• Resource utilization charts based on each activity’s latest start time are said to be based on an as-late-as-possible (ALAP) schedule.
6
Resource Leveling
• Resource leveling, or smoothing, is a method for developing a schedule that attempts to minimize the fluctuations in requirements for resources.
• This method levels the resources so that they are applied as uniformly as possible without extending the project schedule beyond the required completion time.
• Non critical activities are delayed beyond their earliest start times in order to maintain a uniform level of required resources
• Example : Utilization of PaintersLooking at Figure we can see that “Bathroom” could be delayed up to 2 days, “Basement Rooms” could be delayed up to 8 days, and “Bedrooms” could be delayed up to 6 days—all without extending the project completion time
6
Resource Leveling
Two alternative actions could be taken:– Alternative 1. Delay the activity with the most
positive slack—“Basement Rooms” (+8 days slack)—by 6 days so that it will start after “Bedrooms” is finished.
– Alternative 2. Delay “Bedrooms” so that it will start on day 4, after “Basement Rooms” is completed.
Resource-Leveled Utillization
Resource-Leveled Profile for Painters
7
Resource-Limited Scheduling
• Resource-limited scheduling is a method for developing the shortest schedule when the number or amount of available resources is fixed and cannot be exceeded.
• This method will extend the project completion time if necessary in order to keep within the resource limits.
• When several activities need the same limited resource at the same time, the activities with the least slack have first priority
Effect of Limited Resource Availability
what would happen if only a limited number of painters—two—were available to do the painting project.
Original Resource Utilization
Figure below shows that, as the project starts, three activities require a total of four painters
Since “First Floor Rooms” has a slack of 0 the two painters will be allocated to the first floor rooms and will continue to be assigned to that activity until it is finished
First Resource Allocation
This first resource allocation is shown in Figure below with the project completion going from day 12 to day 14.
Second Resource Allocation
• The second resource allocation is shown in Figure below with the project completion date going from day 14 to day 16.
Third Resource Allocation
• The third resource allocation is shown in Figure below with the project completion date remaining at day 16
8
Project Management Software
• Provides excellent features for handling resource considerations within a project.
• Allows you to create and maintain a list of resources.• Resources can be assigned to various tasks within a
project.• The user is informed if any resources have time
conflicts or if they are over-allocated.• Numerous resource allocation reports can be
generated.
Software 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 * CAFWhere CAF = 0.65 + x Fi
Complexity adjustment Factor
1. Does the system require reliable backup and recovery?2. Is data communication required?3. Are there distributed processing functions?4. Is performance critical?5. Will the system run in an existing heavily utilized operational
environment?6. Does the system require online data entry7. Does the online data entry require the input to be built over
multiple screens or operations
Rate each factor on a scale of 0 to 5 0 1 2 3 4 5
No Influence Incidental Moderate Average Significant Essential
Complexity adjustment Factor
8. Are the master files updated online?9. Is the inputs, outputs, files or inquiries complex?10. Is the internal processing complex?11. Is the code designed to be reusable?12. Are conversion and installation included in the design?13. Is the system designed for multiple installations in
different organizations?14. Is the application designed to facilitate change and ease
of use by the user?
Rate each factor on a scale of 0 to 5 0 1 2 3 4 5
No Influence Incidental Moderate Average Significant Essential
Problem
• Consider a project with the following functional units:
• no. of user inputs = 50• No. of outputs = 40• No. of user enquiries = 35• No of user files = =06• No of external interfaces = 04• Assume all CAF and weighting factors are
average. Compute the FP for the project
Answer
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 complexityb) 15 with average complexityc) 17 with high complexity
ii) External outputs:a) 6 with low complexityb) 13 with high complexity
iii) External inquiries:a) 3 with low complexityb) 4 with average complexityc) 2 with high complexity
Example
iv) Internal logical files:
a) 2 with average complexity
b) 1 with high complexity
v) External Interface files
a) 9 with low complexity
In addition to above system required• Significant data communication• Performance is very critical• Designed code may be moderately reusable• System is not designed for multiple installations in different
organizations.
Other complexity adjustment factors are treated as average. Compute the function points for the project
The factor given in table may be calculated as
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!
SoftwareSoftwareProjectProject
PlanPlan
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 equationC = 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 LOCConstants 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 ModelE = 1.4L0.93
DOC = 30.4L0.90
D = 4.6L0.26
WhereE = Effort Person Months DOC = Documentation in number of pages andD =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
SELL = (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 ModelL = (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 modeis 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 = pE• Dp = pD
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 isCost 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 costOR CV = CEV – CAC
• In the packaging machine project, the cost variance as of week 8 is given by
• CV = $54,000 – $68,000 = –$14,000• This calculation indicates that the value of the work
performed through week 8 is $14,000 less than the amount actually expended.
13
Cost Forcasting Three Methods (7A)Based on analysis of actual cost it’s possible to forecast what the total costs will be at the completion of the project or work package.
• There are three different methods for determining the forecasted cost at completion (FCAC).
• The first method assumes that the work to be performed on the remaining portion of the project or work package will be done at the same rate of efficiency as the work performed so far. Forecasted Cost at Completion =F(Total budgeted cost, Cost performance index)
• For the packaging machine project, the forecasted cost at completion is given by:
FCAC = F($100,000,0.79) = $126,582
13
Cost Forcasting Three Methods (7 B)
• A second method for determining the forecasted cost at completion assumes that, regardless of the efficiency rate the project or work package has experienced in the past, the work to be performed on the remaining portion of the project or work package will be done according to budget.
• Forecasted cost at completion =Cumulative actual cost+ (Total budgeted cost – Cumulative earned value)
• For the packaging machine project, the forecasted cost at completion is given by:FCAC = $68,000 + ($100,000 – $54,000)
= $68,000 + $46,000= $114,000
13
Cost Forcasting Three Methods (7C)
• A third method for determining the forecasted cost at completion is to re-estimate the costs for all the remaining work to be performed and then add this re-estimate to the cumulative actual cost.
• FCAC = CAC + Re-estimate of remaining work to be performed
14
Cost Control (8 A)
• The key to effective cost control is to analyze cost performance on a regular and timely basis.
• It’s crucial that cost variances and inefficiencies be identified early so that corrective action can be taken before the situation gets worse.
• Cost control involves the following:– Analyzing cost performance to determine which work packages
may require corrective action– Deciding what specific corrective action should be taken– Revising the project plan—including time and cost estimates—
to incorporate the planned corrective action
14
Cost Control (8 B)
• When evaluating work packages that have a negative cost variance, you should– focus on taking corrective actions to reduce the costs
of two types of activities:• Activities that will be performed in the near term. If you put
off corrective actions until some point in the distant future, the negative cost variance may deteriorate.
• Activities that have a large cost estimate. Taking corrective measures that reduce the cost of a $20,000 activity by 10 percent will have a larger impact than totally eliminating a $300 activity
14
Cost Control (8 C)
• There are various ways to reduce the costs of activities. – One way is to substitute less expensive materials.– Another approach is to assign a person with greater expertise or
more experience to perform or help with the activity.– Reducing the scope or requirements is another way to reduce
costs. – Increasing productivity through improved methods or technology.
• In many cases, there will be a tradeoff—reducing cost variances will involve a reduction in project scope or a delay in the project schedule.
• The key to effective cost control is aggressively addressing negative cost variances and cost inefficiencies as soon as they are identified.
17
Managing Cash Flow
• It is important to manage the cash flow on a project. • Managing cash flow involves making sure that sufficient payments
are received from the customer in time so that you have enough money to cover the costs of performing the project.
• The key to managing cash flow is to ensure that cash comes in faster than it goes out.
• The contractor might try to negotiate payment terms that require the customer to do one or more of the following:– Provide a down payment at the start of the project. – Make equal monthly payments based on the expected duration of the
project. – Provide frequent payments, such as weekly or monthly payments
rather than quarterly payments.• The worst scenario from the contractor’s point of view is to have
the customer make only one payment at the end of the project.
18
Project Management Software
• All costs associated resources can be stored. The software calculates the budget for each work package and for the entire project.
• The software allows the user to define different rate structures for each resource and when charges for those resources will be accrued.
• Cost tables and graphs are available to help analyze cost performance.
Risk Management
Projects can fail for a number of reasons and the risks are always high. While a project manager cannot eliminate risk, he/she can prevent or mitigate its impacts by using risk management.
“If You Don’t Actively Attack the Risks,
The Risks Will Actively Attack You.”
-Tom Gilb
Some definitions of risk
• Risk management is the process of identifying, analyzing, controlling, and reporting risk.
• an uncertain even or condition that, if it occurs, has a positive or negative effect
• The two characteristics of a risk in project management are the following:– It stems from the elements of uncertainty– It might have negative or positive effects on meeting the project
objectives
Some definitions of risk
People may use different terms, but the key elements of a risk follow.
It relates to future:Risk Planning involves speculating about future events. The future is inherently uncertain. Some things which seem obvious when a particular project is over, for example that the costs were under-estimated or that a new technology was overly difficult to use, might not have been so obvious during planning
It involves cause and effectFor 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
Analyzing Risk : Qualitative Risk Analysis
Probability and impact Matrix– The prioritization can be performed by using the probability and
impact matrix – a lookup table that can be used to rate risk based on where it falls both on the probability scale and on the impact scale
A Risk Probability and Impact Matrix for an Objective Probability Impact 0.00 0.05 0.15 0.25 0.35 0.45 0.55 0.65 0.75 0.90 0.10 R11 R12 R13 R14 R15 R16 R17 R18 R19 0.30 R21 R22 R23 R24 R25 R26 R27 R28 R29 0.50 R31 R32 R33 R34 R35 R36 R37 R38 R39 0.70 R41 R42 R43 R44 R45 R46 R47 R48 R49 0.90 R51 R52 R53 R54 R55 R56 R57 R58 R59
Risk R45 has probability of 0.70 (that is, seven out of 10 chances) for occurrence and an impact of 0.45 on the project objective for which this matrix is prepared
How to calculate the numerical scales for the probability and impact matrix and what they mean depends upon the project and the organization
Remember– Higher value of a risk on the probability scale means – Greater
likelihood of risk occurrence– Higher value on the impact scale means- greater effect on the project
objectives
Analyzing Risk : Qualitative Risk Analysis
• Generally Risk Probability and impact matrix is divided into three areas– High Priority Risk– Medium priority risks– Low priority risk
Each organization has to design its own risk score and risk threshold to guide the risk response plan
Note: Impact can be a threat (negative effect) or an opportunity ( a positive effect) – Build separate matrices for threats and opportunities
Threats on the high-priority area might require priority actions and aggressive responses
You may have to capitalize on those opportunities in the high-priority area, which you can do with relatively little effort
Risk posing threats in the low-priority area, might not need any response, but they must be kept on the watch list
Analyzing Risk Output of the Qualitative Risk Analysis
• Risk Categorization• Prioritized list of risk• List of risks with time urgency• Watch list of low-priority list• List of risk for additional analysis and response• Trends in the analysis results
The main output of qualitative risk analysis is the prioritization of risks based on a probability and impact matrix for each objective
Analyzing Risk : Quantitative Analysis
Qualitative Risk Analysis is generally performed on the risks that have been prioritized by using the qualitative risk analysis.
Depending upon the experience of the team and their familiarity with the risk, it is possible to skip the qualitative risk analysis and move directly after the risk identification to the quantitative risk analysis.
The quantitative risk analysis has three major goals:– Assess the probabilities of achieving specific project objectives– Quantify the effect of the risks on the overall project objectives– Prioritize risks by their contributions to the overall project risk
Analyzing Risk : Quantitative Analysis Techniques
Interviewing : This technique is used to collect the data for assessing the probabilities of achieving specific project objectives.– You are looking for results such as: We have a 70% probability of
finishing the project within the schedule desired by the customer
– or perhaps we have a 60% probability of finishing the project within the budget of $1,00,000.
• The goal is to determine the scale of probabilities for a given objectives e.g. there is a 20% probability that the project will cost $50,000, a 60% probability that it will cost $1,00,000, and a 20% probability that it will cost $ 1,50,000
• The data is collected by interviewing relevant stakeholders and subject matter experts . Most commonly, you will be exploring the optimistic (best case), pessimistic (worst case) and most likely scenarios for a given objective.
Analyzing Risk : Quantitative Analysis Techniques
Probability Distributions :After you have collected the data on meeting the
project objectives, you can present it in a probability distribution for each objective under study. Note that distribution represents uncertainty, and uncertainty represents risk.
For example, if you know for sure the project will cost $25 million, there will be no distribution because it is only one data point.
Distribution comes into the picture when you have several possible values with a probability assigned to each value.
Analyzing Risk : Quantitative Analysis Techniques
Sensitivity Analysis:This is a technique used to determine which risk has the greatest
impact on the project.
You study the impact of one uncertain element on a project objective by keeping all other uncertain elements fixed at their baseline values.
You can repeat this analysis for several objectives, one at a time. You can also repeat for several uncertain elements, one at a time.
This way, you can see the impact of each element (or risk) on the overall project separate from other elements.
Analyzing Risk : Quantitative Analysis Techniques
Expected Monetary value Analysis:The expected monetary value (EMV) analysis is used to calculate the
expected value of an outcome when different possible scenarios exist for different values of the outcome with some probabilities assigned to them.The goal here is to calculate the expected final result of a probabilistic
situation
• EMV is calculated by multiplying the value of each possible outcome by the probability if its occurrence and adding the results.– For example: If there is 60% probability that an opportunity will earn you $ 1,000
and a 40% probability that it will only earn you $500, the EMV is calculated as follows:
– EMV = 0.60*1000+0.40*500= 600+200 = 800
• When you are using the opportunities and threats in the same calculation, take opportunity as positive value and for a threat as negative value– For example, if there is a 60% chance that you will benefit from a risk by $1,000
and a 40% probability that you will lose $400 as a result of this risk, the EMV is calculated as follows:
– EMV=0.60*1000-0.40*500 = 600-200=400
Analyzing Risk : Quantitative Analysis Techniques
Decision Tree Analysis:• This technique uses the decision tree diagram to choose from different
available options, each option is represented by a branch of the tree• This technique is used when there are multiple possible outcomes with
different threats or opportunities with certain probabilities assigned to them• EMV analysis is done along each branch, which helps to make a decision
about which option to chooseImplementation
Successful
Update or Build from scratch
Update
Cost=$50,000
Build from Scratch
Cost=$70,000
Implementation Failed
Implementation Successful
Implementation Failed
Probability=40%
Probability=10%
Impact=$2,00,000 Loss of Revenue
Impact=$2,00,000 Loss of Revenue
Example of Decision Tree Diagram
Analyzing Risk : Quantitative Analysis Techniques
Option Initial Cost
Risk Cost Probability EMV for Risk Total Cost
Update $ 50,000 $ 2,00,000 40% 0.40*$2,00,000 = $80,000
50,000+80,000 = $1,30,000
Build From Scratch
$ 70,000 $ 2,00,000 10% 0.10*2,00,000 =$20,000
$70,000+$20,000 =$90,000
Though the initial cost for the update option is less than the initial cost for the build-from-scratch option, the decision will be made in favor of the build-from-scratch option because when you combine the initial cost with the EMV resulting from the probability of failure, the build-from-scratch option turns out to be a better deal
Analyzing Risk Output Quantitative Analysis Techniques
Probabilistic analysis of the project: – This includes the estimates of the project schedule and cost with a
confidence level attached to each estimate.
– Confidence level is expressed in percentage form such as 95% and it represents how certain you are about the estimate
Probability of achieving the project objectives:– Factoring in the project risks, you can estimate the probabilities
of meeting project objectives, such as cost and schedule set forth by the current project plan. For example, the likelihood of completing the project within the current budget plan of $2million is 70%
Prioritized list of risks: Risks are prioritized according to the threats they pose or the opportunities they offer.
Trends in the results: By repeating the analysis several times and by examining the results, you might recognize a trend for specific risk. That trend might suggest further analysis or a specific risk response
Risk prioritization
A common problem with risk identification, particularly for the more anxious, is that a list of risks is potentially endless. Some way is, therefore needed of distinguishing the more damaging and likely risks. This can be done by estimating the RISK EXPOSURE for each risk using the FORMULA
Risk exposure (RE) = (potential damage) x (probability of occurrence)
IdeallyPotential damage: a money value e.g. a flood would cause £0.5 millions
of damageProbability 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)
REbeforeis 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 occur2. 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 Quality
7. Cause and Effect Diagram :A cause and effect diagram is used to explore all the potential causes (inputs) that result in a single effect (output), such as a problem or a defect. This type of diagram is the brainchild of Kaoru Ishikawa, who pioneered quality management process in the Kawasaki Shipyards, and therefore these diagrams are also called Ishikawa Diagrams. Due to the shape of the diagram, it is also called as fishbone diagram. To construct and use cause and effect diagrams effectively, perform the following simple steps:
a) Identify the Problem: Write down the problem in the box drawn on the right side of a sheet of paper. This represents the head of the fish. Starting from the box, draw a horizontal line across the paper. This represents the spine of the fish
b) Identify the possible areas of causes: Identify the areas or factors from where the potential causes of the problem might come. Environment, people, materials, measurements and methods are some examples of areas (factors) of causes. For each factor relevant to the problem under study, draw a line off the spine and label it with the name of the factor. These lines represent the fish bones.
c) Identify the possible causes: For ach factor, identify possible causes. Represent each possible cause with a line coming off the bone that represent the corresponding factor.
d) Analyze the diagram: Analyzing the diagram includes narrowing down the most likely causes and investigating them further
An example of cause and effect diagram
Delay in Web Site
Release
Time
People
Shutdown Periods
Efficiency of Night Shifts
Hiring
Too many Commitments
Shutdown Periods
Methods
Environment
Need
Accuracy
Testing Environment
Development Environment
Efficiency
Cause and Effect Diagram :A cause and effect diagram is a structured way to think through all possible causes of a problem. You can use these diagram to carry out a thorough analysis of a problematic situation
Output of Quality Control
The quality control measurements and recommendations based on those measurements are the obvious outputs items of the quality control process.
Recommended Items:– Recommended Corrective Actions– Recommended Preventive Actions– Recommended Defect Repair– Request Changes
Validated Items– Validated Defect Repair– Validated Deliverables
UpdatesProject management Plan
Quality Baseline
Understanding Project Closure
Understanding Project Closure
Project closure refers to a set of tasks that are required to formally end the project. There are two kinds of projects that you need to close formally:
Completed Projects : A project that has met its completion criteria falls into this category
Terminated Projects: A project that was terminated before its completion falls into this category. A project can be terminated at various stages for various reasons. Following are some examples:– The project management plan is not approved for whatever reason
– The project has been executing but you have run out of resources and no more resources are available
– The project has been cancelled because it was going nowhere
– The project has been indefinitely postponed because there is not a large enough market for the product it would produce
Understanding Project Closure
The process of closure consists of two kinds of tasks: – Establish procedures to co-ordinate the activities needed to close the
project– Implement the procedures
There are two aspects of closing a project:Administrative closure:
– Performing administrative closure of a project includes obtaining final acceptance for the project deliverables, analyzing the project’s success or failure, gathering lessons learned, archiving project information and releasing project resources.
– How will these activities be performed and coordinated, any by whom? For that, you establish an administrative closure procedure for your project that will take into account the relevant policies and procedures of the performing organization
Contract ClosureContract closure includes settling and closing all the contracts associated
with the project. To carry out and co-ordinate the activities needed for the contract closure, you define the contract closure procedure
Understanding Project Closure
Fig. The process to close the project
Close Project
Contract Closure
1. Establish procedures for administrative closure and contract closure
2. Implement Administrative Closure
1. Implement Contract Closure
Integrated Change Control 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
Output of the Project Closure
Administrative Closure procedure: – This procedure specifies the step-by-step methodology for the
administrative closure of the project, which includes specifying all the necessary activities, roles and responsibilities of the project team member who will participate in the closure process. The activities defined by this procedure include the following:
• Activities to define the requirement for getting approval from the stakeholders, such as customers and the sponsor on the project deliverables and the approved changes which were supposed to be implemented
• Activities that are necessary to satisfy the project completion or exit criteria
• Activities related to the project completion, such as:– Confirm that the project has met all requirements– Verify that all deliverables have been provided and accepted– Verify that the completion or exit criteria have been met
Output of the Project Closure
Formal Acceptance for the Final Product: – This includes handing over the final product to
the customer and getting formal acceptance for it – for example, in the form of a receipt that contains statement to the effect that the requirement of the project have been met, including the terms or the contracts
Output of the Project 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 Closure
A project might include work that was procured and that’s where legal agreements, such as contracts, come into the picture. The contracts are closed at the end of a project or a phase by using the contract closure process. Strictly speaking, the contract closure process is used to accomplish the following two goals:– Close all the contract applicable to the project
– Receive verification (if you are seller) or issue verification (if you are a buyer) that all the procured deliverable were received and accepted. In this respect, the contract closure process supports the administrative closure of the project.
• If the project terminates without completion, you still need to go through the contract closure process, if there is a contract. Usually a contract contains the contract termination clause, which contains the terms of the project termination, including the rights and responsibilities of the parties in case of the; project’s early termination
Performing Contract Closure
Closing the contract means that procured work is completed with all its requirement and is accepted.
Generally, it is accomplished by a formal notice from the buyer to the seller, which might come, for example, through the buyer’s authorized administrator
The Finishing Touch – Reviewing the project
Part of the administrative closure is to analyze project success or failure. You can accomplish this by collecting and generating the project evaluation information, such as what went well and what did not
Some of this information already exists in the work performance reports. However, the final information can be gatheredin various ways, such as a post-project review meetings with the team or a questionnaire
The most important output of the review are the lessons learned.
The review should be comprehensive and should cover the following:– Both the technical and non-technical components
– Both positive and negative aspects – that is, the things that went well and the things that did not go well
– All stages and phases of the project
The Finishing Touch – Releasing the Resources
For the effective and efficient use of the organizational resources, it is imperative that they be release in an efficient and proper manner.
The release procedure might be included in the resource planning – for example, the staff management plan should address the issue of releasing the human resources
Following are some suggestions to consider for properly releasing the human resources:– Although it is possible that different team members will be released at
different times, at the project closure you should organize some closure events to honor and than the project team members, including the contractors, for their contributions.
– Plan ahead, and do not wait until the last minute. Communicate with the functional manager ahead of time about when a staff member is going to be released
– Work closely with you organizations human resource department, which might have some guidelines or procedure that you need to follow
– Write recommendation letters for team members who have mad the outstanding contributions to the project
Solution Unit Test 1
Software Project Management
Q1a) Why is it important to determine the critical path of a project? What happens if activities on this path are delayed? What happens if activities on this path are accelerated?
• If any activity on the critical path is delayed, the whole project will be delayed, so it is important to know what the critical path is. If any of these activities are accelerated, the project completion date will also be accelerated.
Q1b)
Give examples of situations in which an individual might develop a request for proposal.
• There are many possible answers to this question. Some examples might include an RFP for a new in-ground pool, a new deck, or a new house.
Q1c) How do customers evaluate proposals? What factors might they consider?
• Customers evaluate contractors’ proposals in many different ways. – Some customers first look at the prices of the various proposals
and select, for example, only the three lowest-priced proposals for further evaluation.
– Other customers initially screen out those proposals with prices above their budget or those whose technical section doesn’t meet all the requirements stated in the RFP.
– Other customers, especially on large projects, create a proposal review team that uses a scorecard to determine whether each proposal meets all requirements in the RFP and to rate the proposal against predefined evaluation criteria, such as price, schedule, capabilities, and experience.
Q1d)
Define proposal, and describe the purpose of a proposal.
• A proposal is a selling document and its purpose is to convince the customer that you understand what the customer wants and that you are the best one for the job.
Q1e) Why should a project have a well-defined reporting period? During each reporting period, what kinds of data need to be collected?
• A regular reporting period should be established for comparing actual progress with planned progress. This must be done on a regular basis to ensure the project is progressing as expected. Reporting may be daily, weekly, bi-weekly, or monthly, depending on the complexity or overall duration of the project. If a project is expected to have an overall duration of a month, the reporting period might be as short as a day. On the other hand, if a project is expected to run five years, the reporting period might be a month.
• During each reporting period two kinds of data or information need to be collected:1. Data on actual performance. This includes
• the actual time that activities were started and/or finished• the actual costs expended and committed
2. Information on any changes to the project scope, schedule, and budget. These changes could be initiated by the customer or the project team, or they could be the result of an unanticipated occurrence such as a natural disaster, a labor strike, or the resignation of a key project team member.
Q2) Calculate the ES, EF, LS, and LF times and the slack for each activity in the figure below and identify the critical path for the project. Can the project be completed in 30 weeks?
Activity ED ES EF LS LF TS 1. Prob. Def. 2 0 2 -5 -3 -5
2. Sys. Analysis 5 2 7 -3 2 -5 3. Design I/O 3 7 10 6 9 -1 4. Design DB 15 7 22 2 17 -5 5. Develop Input 8 10 18 11 19 1 6. Develop Output 10 10 20 9 19 -1 7. Develop DB 2 22 24 17 19 -5 8. Test System 6 24 30 19 25 -5 9. Implement 5 30 35 25 30 -5
No, this project cannot be completed within 30 weeks. With the current estimates, it will take 35 weeks. The most critical path is: 1-2-4-7-8-9.
Q2) Assume that “Systems Analysis” actually finished at 8 weeks, “Design Input & Output” actually finished at 15 weeks, and “Design Database” actually finished at 19 weeks. Recalculate the expected project completion time. Which activities would you focus on in order to get the project back on schedule?
Activity ED ES EF LS LF TS AF 1. Prob. Def. 2
2. Sys. Analysis 5 8 3. Design I/O 3 15 4. Design DB 15 19 5. Dev. Input 8 15 23 11 19 -4 6. Dev. Output 10 15 25 9 19 -6 7. Dev. DB 2 19 21 17 19 -2 8. Test System 6 25 31 19 25 -6 9. Implement 5 31 36 25 30 -6
The project has slipped even further. With the current estimates, it will take 36 weeks. Attention should be given to all activities since they all have negative slack. However, the path 6-8-9 is the most critical
Quiz – Software Planning
________________ is the systematic arrangement of tasks to accomplish an objective.
– scheduling– planning– team building– controlling
• ANSWER: B
• The plan becomes a benchmark against which ______ progress can be compared.
– actual– planned– future– expected
• ANSWER: A
• By participating in ____________ of the work, individuals will become committed to accomplishing it.
– planning– controlling– discussing of– timing
• ANSWER: A
• The _______ step in the planning process is to define the project objective
– first– second– third– fourth
• ANSWER: A
• The project __________ must be clear, attainable, specific, and measurable.
– a. environment– b. cycle– c. objective– d. work forms
• ANSWER: C
• For a project, the objective is usually defined in terms of scope, _______, and cost.
– a. plan– b. schedule– c. controls– d. packages
• ANSWER: B
• The _____________ breaks a project down into manageable pieces, or items, to help ensure that all of the work elements needed to complete the project work scope are identified.
– work package plan– work budget plan– work breakdown staff– work breakdown structure
• ANSWER: D
• _________ Is a hierarchical tree of end items that will be accomplished or produced by the project team during the project.
– work package plan– work budget plan– work breakdown staff– work breakdown structure
• ANSWER: D
• A WBS subdivides the project into smaller pieces called _____________.
– object codes– task statements– work items– work loads
• ANSWER: C
• The lowest-level item of any one branch is called a ___________.
– object item– task statements– work package– work loads
• ANSWER: C
• The ___________________ is a method used to display, in tabular format, the individuals responsible for accomplishing the work items in the WBS.
– responsibility matrix– resource map– responsibility web– task structure
• ANSWER: A
• A _____________ is defined as a piece of work that consumes time.
– action– activity– element– work object
• ANSWER: B
• When all the detailed activities have been defined for each of the work packages, the next step is to graphically portray them in a __________________ that shows the appropriate sequence and interrelationships to accomplish the overall project work scope.
– bubble diagram– network ladder– network diagram– responsibility chart
• ANSWER: C
• The Gantt chart combines the two functions of _____________________.
– planning and leveling– scheduling and evaluating– planning and scheduling– scheduling and controlling
• ANSWER: C