Software

Project
Management

1
 Syllabus

1. Project Management Framework (12)

 Overview of project Management
 Project Organization
 Project management life cycle
 Planning a s/w project
 Role of - Project Manager , Team members ,
 Client & Users in project management

2
2. S/w Project Estimation (25)
 Work Break Down for Project Estimation & setting
 Milestones
 Different methods of estimation
 COCOMO model
 Delphi cost estimation
 Function point analysis.
 Project Management through Microsoft Project(Ms-Project)・
 Introduction
 Gantt Chart
 PERT Chart
 Usage of Microsoft Project for Estimation and Management
 Software Project Metrics
 (Size Oriented, Software Measurement, Function Oriented,
 Object Oriented Metrics)
 Project Scheduling, tracking & Progress reporting
3
 3. Risk Management(10)
 Identification of Risks
 Risk Management Process: Risk identification, Risk analysis,
 Risk planning, Risk monitoring, Risk Closure
 4. Software Quality Management & Control(20)
 Quality Assurance & Standards ; The SEI Capability Maturity
 Model CMM;
 Concept of Software Quality, Software Quality Attributes,
 Software Quality Metrics and Indicators,
 Quality assurance & Validation plan (SQA
 Activities , reviews, walkthroughs, inspection, testing)
 Automation to improve Quality in testing
 Defect Management

4
5. Configuration Management(CM)(13)
 Configuration management & Maintenance plan
 Change Management
 Version and Release Management
 Configuration Management Tools
6. S/W Team Management(12)
 Team Structure & Staff development plan
 Characteristics of Performance management
 High performance Directive and collaborative styles
 Team Communication
 Group Behavior
 Managing customer expectations
5
7. Project Management Tools (8)
 Project management tool like MS Project
 Assignment can be given based on the tool

6
Software Project Management
 Program – set of instructions
 Software
• Computer instructions or data. Anything that can be stored
electronically is software.
• Collection of programs to achieve some goal.

 Project
• A project is a sequence of unique, complex and connected activities
having one goal or purpose and that must be completed in a specific
time within budget and according to requirement specifications.
• A temporary efforts undertaken to create a unique product, service or
result.

7
Software Project Management

• Examples of project
1. A plan or proposal; a scheme.
2. An extensive task undertaken by a student or group
of students to apply, illustrate, or supplement
classroom lessons.
3. A housing project.

8
Management

 Management is an act, manner, or practice of managing,

handling, supervising, or controlling the project activities.
For successful management, manager can control or direct a
business or other enterprise.

Project Management

It is the application of knowledge, skills, tools and techniques to

perform or carry out project activities in order to meet
stakeholders’ need.

Project Management is the discipline of planning, organizing and

managing resources to complete a project within defined scope,
quality and cost constraints.
9
Software Project Management

Software project management is the discipline used for

managing projects effectively. It is a challenging activity and
plays a vital role in the success of a project.
 SPM is nothing but the planning, monitoring and control of
the people, process and events that occur as software evolves
from preliminary investigation to implementation.

10
Software Project Management
 Project Management is the application of knowledge, skills,
tools and techniques to project activities to meet project
requirements. The PMBOK lists nine knowledge areas of PM
 Integration Management
 Scope Management
 Time Management
 Cost Management
 Quality Management
 Human Resource Management
 Communication Management
 Risk Management
 Procurement Management

11
 Who needs software?
Most softwares are built in organizations for people with
specific needs.

A stakeholder is a anyone who has an interest (or stake) in

the software being completed

An user is someone who will need to use the software to

perform tasks.

Sometimes stakeholders will be users; but often the

stakeholder will not use the software.

12
 Who builds software?
 Software is typically built or develop by a team of
software engineers, which includes:

1. Business analysts or requirements analysts who talk to

users and stakeholders, plan the behavior of software
and write software requirements
2. Designers and architects who plan the technical
Solution
3. Programmers who write the code
4. Testers who verify that the software meet its
requirements and behaves as expected

13
 Important Aspects
The 4 P’s
 People — the most important element of a
successful project
 Product — the software to be built
 Process — the set of framework activities and
software engineering tasks to get the job done
 Project — all work required to make the product a reality

14
1.1 Overview of Software Project Management
Important Aspects of SPM - 4 P’s
People

Project Dependency Product

4 order 2

Process

Fig. Factors of management dependency form project to

people 15
People
For successful project people are important aspects in
project.
They could be:
1.Stakeholders
2.Team Leader/Project Manager
3.Software Team
4.Agile Team
5.Coordination and Communication Issues

16
 1.Stakeholders
 Senior managers: who define the business issues that often have
significant influence on the project.
 Project (technical) managers : who must plan, motivate,
organize, and control the practitioners who work on software.
 Practitioners/Programmers : who deliver the technical skills that
are necessary to engineer a product or application.
 Customers : who specify the requirements for the software to be
engineered and other stakeholders who have a peripheral interest
in the outcome.
 End-users : who interact with the software once it is released for
use.

17
 2. Team Leader/Project Manager

Jerry Weinberg model for leadership

1.Motivation : Ability to encourage the people to produce their
best level.

2.Organization : Ability to mold existing process or invent

new one that will be enable to translate initial concept to
final product.

3.Ideas or Innovations : Ability to encourage people to create

and feel creative when they must work within the bounds
established for a particular software product or any
application.
18
Characteristics of Project Manager
 Problem Solving: diagnose and solve organizational and
technical issues
 Managerial Identity : He should be confident and proper
control
 Achievements : He should have to take initiative to
enhance the productivity
 Influence and Team building : Able to read people, able
to communicating with customers and also proper control
in high stress situation.

19
3. Software Team
 Team structure depends on

 Management style of organization

 No. of people in the team
 Their skill level
 Overall problem difficulty and way to find solutions

20
3. Software Team
 There are seven factors for planning a software
team
1. Ways to handle difficulties in problems
2. Size of resultant program in LOC or FPs
3. Time that team will stay together
4. Degree to which problem can be modularized
5. Required quality and reliability of system to be
built
6. Rigidity of delivery date
7. Degree of communication required for project.

21
4. Agile Team
 Agile (Responsive) team means small and highly motivated
team that adopts many characteristics of successful projects
and avoided many toxin that create problems.
 It focus on individual competency and group collaboration
with team.
 Self organizing team.
 Involvement of end users or customers from very first phase
of development.
 It uses closed, random, open and synchronous paradigm for
project organization.

22
Organizational paradigm for Project organization

 Closed Paradigm : Such team work well if they have

past experience but they will be less innovative.
 Random Paradigm : Such team closely depends on
individual initiative of team member. Such team may
struggle when performance is required.
 Open Paradigm : Such team achieve control in
close paradigm but also innovative when use random
paradigm and work is performed collaboratively. It
will suited for complex problem but not perform
efficiently with other teams.

23
Organizational paradigm for Project organization
Synchronous Paradigm :
 It relies on Compartmentalization of a problem and
organize team member to work on piece of problem to
achieve communication between them.
 In agile team planning is minimal & team is allowed to
select own approach and organizational standards.
 It also conduct daily team meetings to coordinate and
synchronize the work that must be achieved for that day.
 Information obtained from daily meetings, team adopts its
approach.
 Continuous self organization and collaboration move agile
team towards completion of software increment.

24
5. Coordination & Communication Issues
 There is need of proper communication and coordination
of software team to avoid trouble in development process.
 Project team must communicate with existing software and
confirm predefined constraints imposed by system.
 To avoid uncertainty, interoperability, team must use
formal as well as informal communication among team
members and between multiple teams.
 Formal communication is achieved through writing,
meeting and other relative communication channels.
 Informal communication is more personnel. Software team
can share their ideas, ask help as problem arise and interact
with team members on daily basis.

25
2.Product
 Software Scope
 Problem Decomposition

26
Software Scope
 Software project scope must be understandable at the management
and technical levels.

 Software scope in nothing but the functions or features that are to

be delivered to end users, the data that are input and output,
content that are presented to users

1. Context : How does the software to be built fit into a larger

system, product, or business context and what constraints are
imposed as a result of the context.
2. Information Objectives : What customer-visible data objects
are produced as output from the software? What data objects are
required for input?
3. Function and Performance: what function does the software
perform to transform input data into output? Are any special
performance characteristics to be addressed?

27
Problem Decomposition
 Problem decomposition is mainly focus on software
requirement analysis. Need to partition problem
into smaller problem that will be more manageable
software functions. Because that will used to make
estimation about cost and schedule.
 It is mainly applied on two areas
1. The functionality that must be delivered
2. The process that will be used to deliver it.

28
Problem Decomposition
Sometimes called partitioning or problem
elaboration.
Once scope is defined
1.It is decomposed into constituent functions.
2.It is decomposed into user-visible objects.
3.It is decomposed into a set of problem classes.
Decomposition process continues until all
functions or problem classes have been defined.

29
3.Process

Software
Engineer

uses

Produces
Process Product

30
3. Process
Project manager decide which process model is most
appropriate for
1. Customer who have requested the product and
people, who will do the work.
2. Characteristics of product itself.
3. Product environment in which software team will
work.

31
3. Process
1. Melding Product and Process:
Project manager decides the set of framework
activities that defined by software organization
are
 Communication
 Planning
 Modeling
 Construction
 Deployment

32
 3. Process
2. Process Decomposition
 Software team have significant degree of flexibility to
choose software process models
 For small scale project use linear sequential model
 If deadline is tight use incremental strategy
 If time constraints are tight and problem can be heavily
computerized use RAD model
 Once process model is chosen apply framework like
communication, planning, modeling, engineering and
deployment.
33
3.Process
 Task required for Small Scale project for
communication activity
1. Develop list of clarification issues
2. Meet with customer to address clarification issues
3. Jointly develop a scope standers
4. Receive statement of scope with all concerns
5. Modify the statement of scope if required.

34
3.Process
 Task required for large Scale project for communication
activity

1. Review customer request

2. Plan and schedule formal meets with customer
3. Prepare working document and agenda for meeting
4. Conduct meeting
5. Jointly develop mini-specs that reflect data, functions &
behavioral features. Alternatively develop use case
6. Review each mini-specs or use case for correction
7. Assemble mini-specs into scoping document
8. Review scope document or collection of use cases with all
concerned.
9. Modify scoping document or use case as required.
35
4.Project

Project get into trouble when…

1. Software people don’t understand the customer needs.

2. The product scope is poorly defined.
3. Changes are managed poorly.
4. The chosen technology changes.
5. Business needs changes.
6. Deadlines are unrealistic.
7. Users are resistant.
8. Sponsorship is lost (or was never properly obtained)
9. The project team lacks people with appropriate skills.
10. Managers (and Practitioners) avoid best practices.
36
4. Project
 Reel suggest five common sense approach to software
projects
1. Start on right foot
2. Maintain Momentum
3. Track Progress
4. Mark smart decisions
5. Conduct a postmortem analysis

37
 1.Start on right foot
 This is achieved by working hard to understand
problem.
 Set objectives and expectations for everyone who
involves in project
 It helps to build right team and giving the authority
and technology to do the job .

38
2.Maintain Momentum
 Many project get good start & then slowly disintegrate
 To maintain momentum, project manager must
provide incentives to keep turnover of personnel
 Project Manager should motivate team members
 Sr. Manager should do everything possible to stay out
of the team way.

39
3. Track Progress
 Need to track the progress e.g. models, source code,
test cases etc.
 Focus on quality assurance part
 Also focus on software process and project metrics

40
4. Mark smart decisions
 Decision of project manager and software team should
be kept simple
 Whenever possible use existing software components
 Avoid routine interfaces when standerd approaches
available
 Identify and avoid risks

41
5.Conduct a postmortem analysis
 Evaluate planned and actual schedule
 Collect and analyze software metrics
 Get feedback from team members and customers
 Record findings in written form.

42
1.2 Project Organization
 People Organization
 Team Organization
 Organizational Paradigm
 Molding Product & Process
 Reel’s Common sense Approach to Projects

43
 People Organization
 It is nothing but applying human resources to a project.
 For applying human resources number of possibilities
will be there based on skills, number of functions,
processes, teams etc.
 n<task
 n>task
 n=task

44
Team Organization
 Best team structure depends on management style of an organization.
 There are three form of team organization that will be totally depends
upon skill level and problem difficulty.

1. Democratic Decentralized (DD)-

 no permanent leader
 tasks are assigned for short duration.
 Sometimes leader may be replaced by others who coordinate
different tasks.
 Any decision will be made by considering group concern.
 Horizontal Communication.

45
Team Organization
2. Controlled Decentralized (CD) –
 Primary leader coordinate main task & secondary leader that have
responsibility for subtasks.
 Problem solving is group activity.
 Team leader makes partition of tasks to implement solution
among subgroups.
 vertical as well as horizontal communication.
3. Controlled Centralized (CC)-
 All the work like problem solving & internal team coordination
managed by team leader.
 coordination between team leader & member is vertical.

46
Organizational Paradigm
1. Closed Paradigm
2. Random Paradigm
3. Open Paradigm
4. Synchronous Paradigm

47
 Melding Product & Process
 Planning start with melding of product & process. Any organization
adopted following set of framework activities
1.Customer Communication – required to establish requirement
elicitation between developer and customer.
2. Planning – required for defining resources, time period & other
project related information.
3. Risk Analysis – Assess both technical as well as business risks.
4. Engineering – required for building one or more representation of
application(s).
5.Construction and Release – task required for constructing, testing,
installing & providing users support.
6. Customer Evaluation – Tasks required to obtain customer feedback
based on evaluation of software representation created during the
engineering activities & implemented during construction activity.
48
1.3 Planning A Software Project

1. Software Scope & feasibility

2. Risk analysis
3. Resources
- Human resources
- Reusable Software resources
- Environmental resources
4) Define Cost and Effort
5) Develop Project Schedule

49
1.Software Scope & feasibility
 Software scope in nothing but the functions or features
that are to be delivered to end users, the data that are
input and output, content that are presented to users.
 Scope is defined by using two techniques
1. A narrative description of software scope is delivered
after communication with stakeholders.
2. A set of use cases is developed by end users.

50
 2.Resources
 Description of Resource
 A statement of availability of resources
 Time when resource will required
 Duration of time that resource will applied

Software
Number Tools
Skills
Hardware
Tools
People Environment
Location
Network
Project Resources

Off-The-Shelf New
Components Reusable Components
Software
Full Partial
Experience Experience
Components Components

51
1 Human Resources
 Human resources depends on the size of project i.e. it
must be in Person-month.
 Human resources determined only after an estimation
of development is made.
 For estimation PM use COCOMO,FPA , Delphi etc.

52
 2.Reusable Software Resources
 It mainly focus on reusability.
 Bennatan suggests four software resources categories that
should be considered as planning proceeds
1.Off-the-shelf-components
2.Full experience components
3.Partial experience components
4.New Components

53
3.Environmental Resources
 Environment that supports a software project is
called software engg. Environment (SEE)
including software and hardware.
 Hardware provide platform that supports
software to produce work product.
 Project Manager must described time window for
hardware & software and also verify this
resources will be available or not.

54
Project Management Life Cycle

55
PMLC
1. Project Initiation
 Conceiving and Define Project

 The purpose of the Project Initiation Phase is to define and authorize

the project.
 The initial definition of the project can come from several places...
 Project Statement of Work (SoW)
 Business Case
 Contract

56
 The project manager takes the information provided and creates
a Project Charter. The Project Charter authorizes the project and
documents the initial requirements for the project.
 It generally includes information such as...
 Project purpose, vision, and mission
 Measurable objectives and success criteria
 High level project description, requirements, and risks
 Summary milestone schedule and budget
 Name and authority of the project sponsor
 An important part of starting your project off right is performing
astakeholder analysis. Understanding which people or organizations
will be impacted by or can influence your project is critical for ensuring
your project's success.

57
2. Project Planning
 Begin with WBS

 Time required for each sub unit

 Sequence of sub units

 Parallel sub units

 Estimation

 Risk Management /strategy

 Schedule(WBS)

 Resources

 Staff organization (Team Structure)

 Tracking & Control Mechanism (Quality Assurance & Control,

change management)

58
 The purpose of the Project Planning Phase is to determine the approach you
will take and define all the details of how the project will be done.
 Project Planning has two parts...
 Strategic Planning
 Implementation Planning.
 During Strategic Planning you develop the overall approach to the project.
During Implementation Planning you figure out all the details of how the
project will be done.
 A good way to visualize this is to think of your project as a family vacation.
 During Project Initiation you determine where you want to go (your
mission).
 During Strategic Planning, you decide whether you want to fly there or
drive (your approach).
 Let's say you decide to drive. In that case, during Implementation Planning
you would map out your route, identify which hotels you will stay at along
the way, determine how long each leg of the trip will take, and so on (all the
details).
59
3. Project Execution
• Planning for the final testing, production, and support.

 The purpose of the Project Execution Phase is to carryout the activities

defined during the Project Planning Phase.
 Project Execution is where most of the time, money, and people are used on
a project. This is where the action takes place.
 During this phase the project manager has to keep all the activities moving
forward in a coordinated manner. This means you will need to track the
progress of each activity and adjust your plans when the situation changes.
This tracking and adjustment of project activities is also known as Monitor
and Control.
 During the execution phase all of the agreed project deliverables should be
implemented and accepted by the customer. The customer can be an internal
customer or an external customer.

60
4. Project Closure
 Written formal project review report
 The purpose of the Project Closure Phase is to formally close the project.
 During Project Closure, there are several key activities that need to be
performed...
 Verify that the completion criteria are met
 Create a project closure report
 Collect and archive project artifacts
 Perform a project postmortem
 Many projects skip this phase. Once the Execution Phase is complete, they
simply move on. It's unfortunate since they really don't know if the project
objectives have been met, don't organize the project artifacts to be easily
found for future project's reference, and don't identify the key issues and
lessons learned by the project that can be applied to future projects.
 Performing Project Closure will benefit both your company and your career.
If you do this well, you will set yourself up to lead high-visibility, business-
critical projects. So make sure your projects go through the full project
management life cycle. 61
Chap. 3.
Risk Management(10)
 Identification of Risks
 Risk Management Process: Risk identification,
Risk analysis,
 Risk planning, Risk monitoring, Risk Closure

62
Introduction
 “If you don’t actively attack the risks, they will actively
attack you”.
 Risks concerns future happenings
 Risk involves change such as changes of mind,
opinion, actions or places.
Risk Management
 SEI identifies seven principles that provide a
framework to achieve effective risk
management.

1. Maintain a global perspectives

2. Take a forward-looking view
3. Encourage open communication
4. Integrate
5. Emphasize a continuous process
6. Develop a shared product vision
7. Encourage teamwork
64
Risk Management
1.Maintain a global perspectives
- view software risks within context of system
- business problem that is to be solved
2. Take a forward-looking view
- Think about future risks (due to change)
- establish plans to avoid risks in future.
3. Encourage open communication
- Encourage all stakeholders & users to suggest
risks at any time
- It should be formal or informal
65
Risk Management
4. Integrate
- consideration of risks must be integrated in software
process
5. Emphasize a continuous process
- Team should be alert throughout the software process
- modified in identified risk & add new information that will
be resolve risks in future.
6. Develop a shared product vision
- stakeholder should share the software vision
- So better identification & assessment will occur.
7. Encourage teamwork
- project manager / stakeholder should conduct risks
management activity very successfully for that they can use
their knowledge, skills & talent 66
Risk Analysis
 When risk will be analyzed , it is important to
qualify the level of uncertainty and the degree of
loss associated with each risk.

 There are two characteristics of risk

1. Uncertainty- 100% may or may not be.
2. Loss- if the risk become realilty, loss will be
occurred.

67
Risk Analysis
There are three categories of risks
1. Project Risk
2. Technical Risk
3. Business Risk

1.Project Risk

- It is mainly focus on Analysis phase of SDLC

- project schedule will slip & cost will increase
- It will identified by considering budget, schedule, personnel, resource,
stakeholder, requirement problems & their impact on software project.

2.Technical Risk
- It is mainly focus on Design phase & coding phase of SDLC
- Threats the quality as well as time period
- it will identified by considering design, implementation, interface,
verification & maintenance problems.
-It is mainly focus on technical aspects of the software components.
68
Risk Analysis
3. Business Risk
- Breaks the viability (capability) of the software
- There are five business Risks
- There are five types of business risk
i) Market Risks- Build excellent product or system that no
one really wants.
ii) Strategic Risk- build a product that no longer fits into
overall business strategy for the company.
iii) Sales Risk- Build the product that sales force doesn't
understand how to sell.
iv) Management Risk- due to support, change in people,
change in focus.
v) Budget Risk- loosing budgetary or personnel commitment.

69
Risk Analysis
 There are also three general categories of risks

1.Known Risks- those risk that can be uncovered after careful

evaluation of the project plan, business & technical
environment in which the project is being developed and
other reliable information resources.

2.Predictable Risks- This are those from the past experience

project like staff turnover, poor communication with
customer etc.

3.Unpredictable Risks- these are extremely difficult to

identify in advance.

70
 Identification of Risks
 Risk identification is systematic approach to specify
threats in plan by considering estimate, schedule, resource
allocation etc.
 By identify known & predictable risk project manager can
avoid them & whenever possible control them.
 There are two types of risks for each of the categories

1. Generic Risks
- This is potential threat to every software.

2. Product-Specific Risks
- This is identified only by those with clear understanding
of technology, the people & the environment i.e. specific
software to be built.
- for identification of this risk project manager can review
project plan, scope statement.
-Project Manager can use risk item checklist 71
Risk Item Checklist
1. Product Size- overall size
2. Business Impact- constraint by management or
marketplace
3. Customer Characteristics- sophistication of customer as
well as developer’s ability to communicate customer in
timely manner.
4. Proceeds Definition- degree of process & followed by
development organization
5. Development Environment- availability
& quality of tools to be used to build the product
6. Technology to be built- Complexity of the system to be
built & newness of technology
7. Staff size & Experience- overall technical & project
experience of software engineers who will do the work.
72
Assessment of Overall Project Risk
1. Have top software & customer managers formally
committed to support the project?
2. Are end-users enthusiastically committed to the
project and the product to be built?
3. Are requirement fully understood by the software
engineering team & its customers?
4. Have customers been involved fully in the definition
of requirements?
5. Do end-users have realistic expectations?

73
Assessment of Overall Project Risk
6. Is project scope stable?
7. Does the software engineering team have the
right mix of skills?
8. Are project requirements stable?
9. Does the project team have experience with the
technology to be implemented?
10. Is the number of people on the project team
adequate to do the job?
11. Do all customer/user constituencies agree on the
importance of the project and on the
requirements for the system/product to be built?
74
Risk Components & Drivers
1. Performance Risk- the degree of uncertainty that
the product will meet its requirements and be fit
for its intended use.
2. Cost Risk- the degree of uncertainty that the
project budget will be maintained.
3. Support Risk- the degree of uncertainty that the
resultant software will be easy to correct, adapt &
enhance.
4. Schedule Risk- the degree of uncertainty that the
project schedule will be maintained & that the
product will be delivered on time.
75
Risk Components & Drivers
 Impact of each risk driver on the risk component is
divided into four impact categories
1. Negligible
2. Marginal
3. Critical
4. catastrophic

76
 Category/ Performance Support Cost Schedule
Components

Catastrophic 1 Failure to meet the requirement would Failure results in increased cost & schedule delays
(1) result in the mission failure with expected values in excess of Cost & size

2 Significant Nonresponsive or Significant financial Unachievable Size

degradation to unsupportable shortages, budget
nonachivement of software overrun
technical performance
Critical 1 Failure to meet the requirements would Failure meets in operational delays and/or
(2) degrade system performance to a point increased costs with expected value of size
where mission success is questionable

2 Some reduction in Minor delays in Some shortage of Possible slippage in

technical performance software financial resources, Size
modifications possible overruns

Marginal 1 Failure to meet the requirements would Costs, impacts and/or recoverable schedule slips
(3) result in degradation of secondary mission with expected value of cost and size
2 Minimal to small Responsive Sufficient financial Realistic achievable
reduction in technical software support resources schedule
performance

Negligible 1 Failure to meet the requirement would Error results in minor cost and/or schedule impact
(4) create inconvenience or nonoperational with expected value less than size and cost
impact

2 No reduction in Easily supportable Possible Budget Early Achievable As

technical performance Software Underrun per the Size

77
Risk Projection
 It is also called risk Identification and it is used by two
ways

1. Probability that the risk is real

2.Consequences of the problem associated with the risk

78
Steps of Risk Projection
1.Establish a scale that reflects the perceived probability
of risk
2. Delineate the consequences of the risk
3.Estimate the impact of the risk on the project and the
product
4.Note the overall accuracy of the risk projection so that
there will be no misunderstandings

79
 Risk Projection : Develop Risk Table
 Risk table provides a project manager with a simple
technique for risk projection
Risks Category Probability Impact RMMM

Size estimate may be significant low PS 60% 2

Larger No. of users than planned PS 50% 3

Less reuse than planned PS 30% 2

Funding will be lost CU 50% 1

Staff turnover will be high ST 60% 2

80
RMMM:
Risk Mitigation, Monitoring & Management

 All the risk analysis activities have single goal – to

assist the project team in a developing strategy for
dealing with risk.
 An effective strategy consider the three issues
1. Risk Avoidance
2. Risk Monitoring
3. Risk Management & contingency Planning

81
Risk Mitigation
 For Risk Mitigation (improvement) following steps
will be taken
1. Meet with current staff to determine causes for
turnover like poor working conditions, low pay,
competitive job market etc.
2. Mitigate those causes that are under our control
before the project starts.
3. Once the project commences, assume turnover will
occur & develop techniques to ensure continuity
when people leave.

82
Risk Mitigation
4.Organize project teams so that information about each
development activity is widely dispersed.
5.Define a documentation standards and establish
mechanism to ensure that documents are developed in
a timely manner.
6. Conduct peer reviews off all work.
7. Assign a backup staff members for every critical
technologist.

83
Risk Monitoring
 Project tracking with following primary activities
1. Assess whether predicted risk
2. Assure about risk aversion
3. Collect useful information for future risk

84
Risk Monitoring
 For monitoring risks, and in case of high turnover
following factors should be monitored
1. General attitude of team members based on project
pressure.
2. The degree to which the team has jelled (shape-up).
3. Interpersonnel relationship among team members.
4. Potential problems with compensation and benefits.
5. The availability of jobs within the company and outside it.

85
RMMM
 Risk Management must be included in software
project plan or apply separate RMMM Plan
 RMMM Plan documents all work performed as a
part of risk analysis and is used by the Project
Manager as a part of overall project plan.
 Some team focus on RIS (Risk Information
Sheet)instead of RMMM.
 RIS is maintained using database system so creation
entry, priority order, searches and other analysis
takes place.

86
RIS
 Risk Id, Date, probability and Impact
 Description
 Refinement/Context
 Mitigation/monitoring
 Management
 Current status (Include Date)
 Originator and Assigned

87
Risk Management Steps
 Risk management model

Risk Identification
Risk
Assessment Risk Analysis
Passive
activity
Risk Risk Prioritization
Management

Risk Management Planning

Active
activity
Risk Resolution
Risk
Control
Risk Monitoring
Identification of Risk
 Risk Identification

Check Lists
Risk
Decision Driver Analysis
Identification

Assumption Analysis

Decomposition
Identification of Risk
 Risk identification consists of listing all of the risks that can adversely
affect the successful execution of the project.
 Identifying risk early provides the management with a lot of time to
efficiently handle the risks.
 Risk identification is a systematic attempt to specify threats to the
project plan.
 By identifying known and predictable risks, the project manager takes
a first step towards avoiding them when possible and controlling them
when necessary.
 One method for identifying risks is to create a risk item checklist.
Analysis of Risk
1. Risk analysis is the next task that involve the subjective analysis of the risks
identified.
2. Risk analysis can be done by estimating the worst case value of the size and all the
cost drivers and then estimating the project cost from these values.
3. Using the worst case effort estimate, the worst case schedule can easily be obtained.
4. The other approaches for risk analysis includes studying the probability and the
outcome of possible decisions (decision analysis).
5. Understanding the task dependencies to decide critical activities and the
probability and cost of their not being completed on time (network analysis).
6. Risks on various quality factors for reliability and usability (quality factor analysis).
7. Evaluating the performance early through simulation, etc. if there are strong
performance constrains on the system (performance Analysis).
Prioritize the Risks
 The purpose of this step is to answer the following questions and
initiate any immediate action that might be required:
 Is this a previously reported defect, or is it new?
 What priority should be given to fixing this defect?
 What steps should be taken to minimize the impact of the defect prior to a
fix? For example, should other users be notified of the problem? Is there a
work-around for the defect?
 A suggested prioritization method is a three-level method, as follows:
 Critical: Would cause the software to stop.
 Major: Would cause an output of the software to be incorrect.
 Minor: Something wrong, but it does not directly affect the user of the
system, such as a documentation error or cosmetic GUI error.
Respond to Risks
1. Next step is to respond to the risk based on prioritization
of risk
2. which involve identification of solution of the risk
3. Management people with an expertise involve in this
process.
Resolve, Monitor and Managing the Risks
Plans are developed for each identified risks that needs to be controlled.
Many risks might be combined together for the purpose of planning,
if they require similar treatment. A basic risk management plan has
five component.
1. Why the risk is important and why it should be managed;
2. What should be delivered regarding risk management and when
3. Who is responsible for performing the different risk management
activities.
4. How will the risk be adopted or the approach be taken.
5. How many resources are needed.
Risk Management Planning & Monitoring
 RM planning

Milestone Tracking

Top-10 Tracking
Risk
Monitoring
Risk reassessment

Corrective Action
Monitoring the Risks
 Risk monitoring is the activity of monitoring the status of
various risks and their control activities.
 Like project monitoring, it is performed through the entire
duration of the project like many monitoring activities, a
checklist is useful for monitoring.