8 project planning
DESCRIPTION
TRANSCRIPT
![Page 1: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/1.jpg)
1
Planning a Software ProjectFrom
Pankaj Jalote’s book
![Page 2: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/2.jpg)
2
Agenda
• Background• Process planning• Effort estimation • Schedule and resource estimation• Quality Planning• Risk management• Configuration Management• Project monitoring plans
![Page 3: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/3.jpg)
3
Software Project
• Goal: Build a software system to meet commitments on cost, schedule, quality
• Worldwide - many projects fail– one-third are runaways with cost or schedule
overrun of more than 125%
![Page 4: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/4.jpg)
4
Project Failures
• Major reasons for project runaways– unclear objectives– bad planning– no project management methodology– new technology– insufficient staff
• All of these relate to project management• Effective project management is key to
successfully executing a project
![Page 5: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/5.jpg)
5
Why improve PM?
• Better predictability leading to commitments that can be met
• Lower cost through reduced rework, better resource mgmt, better planning,..
• Improved quality through proper quality planning and control
• Better control through change control, CM, monitoring etc.
![Page 6: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/6.jpg)
6
Why improve PM ….
• Better visibility into project health and state leading to timely intervention
• Better handling of risks reducing the chances of failure
• All this leads to higher customer satisfaction• And self and organization improvement
![Page 7: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/7.jpg)
7
Two Dimensions in project execution
![Page 8: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/8.jpg)
8
Process-based Project Execution
• Small project both engg and PM can be done informally
• Large projects require formality• Formality: well defined processes used for each
task; measurements used to control• Here we focus on processes for PM only
![Page 9: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/9.jpg)
9
The Project Mgmt Process
• Has three phases - planning, monitoring and control, and closure
• Planning is done before the main engineering LC (Life Cycle) and closure after the LC
• Monitoring phase is in parallel with LC
![Page 10: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/10.jpg)
10
Project Planning
• Basic objective: To create a plan to meet the commitments of the project, I.e. create a path that, if followed, will lead to a successful project
• Planning involves defining the LC process to be followed, estimates, detailed schedule, plan for quality, etc.
• Main output - a project management plan and the project schedule
![Page 11: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/11.jpg)
11
Key Planning Tasks
• Define suitable processes for executing the project
• Estimate effort• Define project milestones and create a schedule• Define quality objectives and a quality plan• Identify risks and make plans to mitigate them• Define measurement plan, project-tracking
procedures, training plan, team organization, etc.
![Page 12: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/12.jpg)
12
Process Planning
• Plan how the project will be executed, I.e. the process to be followed
• Process will decide the tasks, their ordering, milestones
• Hence process planning is an important project planning task
• Should plan for LC and PM processes as well as supporting processes
![Page 13: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/13.jpg)
13
Life Cycle Process
• Various LC models - waterfall, iterative, prototyping; diff models suit different projects
• During planning can select the model that is best for the project
• This gives the overall process which has to be fine-tuned to garb the project needs
• Usually done by process tailoring - changing the process to suit the project
• Tailoring finally results in adding, deleting, modifying some process steps
![Page 14: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/14.jpg)
14
Effort Estimation
![Page 15: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/15.jpg)
15
Effort Estimation
• For a project total cost and duration has to be committed in start
• Requires effort estimation, often in terms of person-months
• Effort estimate is key to planning - schedule, cost, resources depend on it
• Many problems in project execution stem from improper estimation
![Page 16: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/16.jpg)
16
Estimation..
• No easy way, no silver bullet• Estimation accuracy can improve with more
information about the project• Early estimates are more likely to be inaccurate
than later – More uncertainties in the start– With more info, estimation becomes easier
![Page 17: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/17.jpg)
17
Estimation accuracy
![Page 18: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/18.jpg)
18
Effort Estimation Models..
• A model tries to determine the effort estimate from some parameter values
• A model also requires input about the project, and cannot work in vacuum
• So to apply a model, we should be able to extract properties about the system
• Two types of models - top-down and bottom-up
![Page 19: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/19.jpg)
19
Effort Estimation Models
Extract Estimation Model
Values of somecharacteristics
Effort Estimate
Knowledge aboutSW project
![Page 20: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/20.jpg)
20
Top-down Estimation
• First determines the total effort, then effort for components
• Usually works with overall size• One method is to see estimate as a
function of effort; the common function used is
E = a * size b
• E (Effort) is in person-months, size in KLOC
• Constants a and b determined through regression analysis of past project data
![Page 21: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/21.jpg)
21
Top down estimation
• Can also estimate from size and productivity– Get the estimate of the total size of the software– Estimate project productivity using past data
and project characteristics – Obtain the overall effort estimate from
productivity and size estimates
• Effort distribution data from similar project are used to estimate effort for different phases
![Page 22: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/22.jpg)
22
Bottom-up Estimation
• Effort for components and phases first estimated, then the total
• Can use activity based costing - all activities enumerated and then each activity estimated separately
• Can group activities into classes - their effort estimate from past data
![Page 23: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/23.jpg)
23
An Estimation Procedure
• Identify programs in the system and classify them as simple, medium, or complex (S/M/C)
• Define the average coding effort for S/M/C • Get the total coding effort.• Use the effort distribution in similar projects to
estimate effort for other tasks and total• Refine the estimates based on project specific
factors
![Page 24: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/24.jpg)
24
COCOMO Model for Estimation
• Is a top-down approach• Uses size, but adjusts using some factors• Basic procedure
– Obtain initial estimate using size– Determine a set of 15 multiplying factors from different
project attributes– Adjust the effort estimate by scaling it with the final
multiplying factor
![Page 25: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/25.jpg)
25
COCOMO..
• Initial estimate: a * size b ; some standard values for a, b given for diff project types
• There are 15 cost driver attributes like reliability, complexity, application experience, capability, …
• Each factor is rated, and for the rating a multiplication factor is given
• Final effort adjustment factor is the product of the factors for all 15 attributes
![Page 26: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/26.jpg)
26
COCOMO – Some cost drivers
Cost Driver Very low
Low Nominal
High Very High
Required reliabilityDatabase sizeProduct complexityExecution time constraintMemory constraintAnalyst capabilityApplication experienceProgrammer capabilityUse of software toolsDevelopment schedule
.75
.7
1.461.291.421.241.23
.88
.94
.85
1.191.131.171.101.08
1.01.01.01.01.01.01.01.01.01.0
1.151.081.151.111.06.86.91.86.911.04
1.41.161.31.31.21.71.82.70.831.1
![Page 27: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/27.jpg)
27
COCOMO – effort distribution
• Effort distribution among different phases is given as a percent of effort
• Eg. For medium size product it is– Product design – 16%– Detailed design – 24%– Coding and UT – 38%– Integration and test – 22%
![Page 28: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/28.jpg)
28
Sizing With Function Points
![Page 29: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/29.jpg)
29
Sizing
• Effort for project depends on many factors• Size is the main factor – many experiments and
data analysis have validated this• Size in the start is only an estimate; getting size
estimates from requirement is hard• Need a size unit that can be “computed” from
requirements• Function points attempt to do this
![Page 30: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/30.jpg)
30
Function Points
• Is a size measure like LOC• Determined from SRS• Defines size in terms of “ functionality “• Why “measure” size early ?
– Needed for estimation and planning
• Five different parameters– external input type– external output type– logical internal file type– external interface file type– external inquiry type
![Page 31: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/31.jpg)
31
Function Points…
• These five parameters capture the functionality of a system
• within a type , an element may be simple , average or complex
• A weighted sum is taken External input type : • each unique input type• A input type is unique if the format is
different from others or if the specifications require different processing.
![Page 32: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/32.jpg)
32
Function Points…
• Simple : a few data elements• Complex : many data elements and many internal
files needed for processing• Only files needed by the application are counted.
( HW/OS config. Files are are not counted ) External output type :• each unique output that leave system boundary• E.g.
– Reports , messages to user , data to other applications
• Simple : few columns
![Page 33: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/33.jpg)
33
Function Points…
• Average : many columns• Complex : references many files for
production Logical internal file type : • An application maintains information
internally for its own processes• Each logical group of data generated , used
and maintained• Same for simple , average and complex
![Page 34: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/34.jpg)
34
Function Points…
• External interface file type– logical files passed between application
• External inquiry type– input , output combination
• Weights– External Input 3 4 6– External Output 4 5 7– Logical int. file 7 10 15– External int. file 5 7 10– External inquiry 3 4 6
![Page 35: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/35.jpg)
35
Function Points…
Unadjusted function point :• Basic function points• Adjusted for other factors• 14 such factors
– performance objectives , transaction rate etc.
• Final FP is adjusted– differs at most 35%
![Page 36: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/36.jpg)
36
Function Points…
• Interest in FP – since obtained at requirements => major
advantage
• Well correlated with size– in some what interchangeable and tables exist
• 1 FP = 70 LOC of C• Works well for MIS , but not for system type• Major draw back - subjectivity
– not repeatable– not precisely known ever for a built system – not addictive
![Page 37: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/37.jpg)
37
Scheduling and Staffing
![Page 38: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/38.jpg)
38
Project Schedule
• A project Schedule is at two levels - overall schedule and detailed schedule
• Overall schedule comprises of major milestones and final date
• Detailed schedule is the assignment of lowest level tasks to resources
![Page 39: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/39.jpg)
39
Overall Schedule
• Depends heavily on the effort estimate• For an effort estimate, some flexibility exists
depending on resources assigned• Eg a 56 PM project can be done in 8 months (7
people) or 7 months (8 people)• Stretching a schedule is easy; compressing is
hard and expensive
![Page 40: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/40.jpg)
40
Overall Scheduling...
• One method is to estimate schedule S (in months) as a function of effort in PMs
• Can determine the fn through analysis of past data; the function is non linear
• COCOMO: S = 2.5 E 3.8 • Often this schedule is checked and corrected
for the specific project• One checking method – square root check
![Page 41: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/41.jpg)
41
Determining Overall Schedule from past data
Effort in person-days
0
50
100
150
200
250
300
350
400
0 200 400 600 800 1000 1200 1400 1600 1800
Sch
ed
ule
(D
ays
)
![Page 42: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/42.jpg)
42
Determining Milestones
• With effort and overall schedule decided, avg project resources are fixed
• Manpower ramp-up in a project decides the milestones
• Manpower ramp-up in a project follows a Rayleigh curve - like a normal curve
• In reality manpower build-up is a step function
![Page 43: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/43.jpg)
43
Manpower Ramp-up
Design Build Test
PTS
![Page 44: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/44.jpg)
44
Milestones ...
• With manpower ramp-up and effort distribution, milestones can be decided
• Effort distribution and schedule distribution in phases are different
• Generally, the build has larger effort but not correspondingly large schedule
• COCOMO specifies distr of overall sched. Design – 19%, programming – 62%, integration – 18%
![Page 45: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/45.jpg)
45
An Example Schedule
# Task Dur. (days)
Work (p-days)
Start Date
End Date
2 Project Init tasks 33 24 5/4 6/23
74 Training 95 49 5/8 9/29
104
Knowledge sharing
78 20 6/2 9/30
114
Elaboration iteration I
55 55 5/15
6/23
198
Construction iteration I
9 35 7/10
7/21
![Page 46: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/46.jpg)
46
Detailed Scheduling
• To reach a milestone, many tasks have to be performed
• Lowest level tasks - those that can be done by a person (in less than 2-3 days)
• Scheduling - decide the tasks, assign them while preserving high-level schedule
• Is an iterative task - if cannot “fit” all tasks, must revisit high level schedule
![Page 47: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/47.jpg)
47
Detailed Scheduling
• Detailed schedule not done completely in the start - it evolves
• Can use MS Project for keeping it• Detailed Schedule is the most live document for
managing the project• Any activity to be done must get reflected in the
detailed schedule
![Page 48: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/48.jpg)
48
An example task in detail schedule
Module Act Code
Task Duration Effort
History PUT Unit test # 17
1 day 7 hrs
St. date End date
%comp Depend. Resource
7/18 7/18 0% Nil SB
![Page 49: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/49.jpg)
49
.Project Scheduling…..
• The scheduling process
Estimate resourcesfor activities
Identify activitydependencies
Identifyactivities
Allocate peopleto activities
Create projectcharts
Softwarerequirements
Activity chartsand bar charts
![Page 50: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/50.jpg)
50
..Project Scheduling….
• Graphical notations used in software project scheduling:– Tables: summary description of tasks – Bar charts: show schedule against the time– Activity charts: graphs that depict dependencies
between tasks and indicate the critical path (the longest path in the activity graph)
![Page 51: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/51.jpg)
51
…Project Scheduling…
• Example of tabular description [Fig. 5.5, SE-7]:
![Page 52: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/52.jpg)
52
….Project Scheduling..
• Example of activity chart
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/03
8 days
14/7/03 15 days
4/8/03
15 days
25/8/03
7 days
5/9/03
10 days
19/9/03
15 days
11/8/03
25 days
10 days
20 days
5 days25/7/03
15 days
25/7/03
18/7/03
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
![Page 53: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/53.jpg)
53
…..Project Scheduling.
• Example of bar chart
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1T2
M1
T7T3
M5T8
M3
M2T6
T5M4
T9
M7T10
M6
T11M8
T12
Start
Finish
![Page 54: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/54.jpg)
54
……Project Scheduling
• Staff allocation chart
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
![Page 55: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/55.jpg)
55
Detail schedule
• Each task has name, date, duration, resource etc assigned
• % done is for tracking (tools use it)• The detailed schedule has to be consistent with
milestones– Tasks are sub-activities of milestone level activities,
so effort should add up, total schedule should be preserved
![Page 56: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/56.jpg)
56
Team Structure
• To assign tasks in detailed schedule, need to have a clear team structure
• Hierarchic team org is most common– Project manager has overall responsibility; also does
design etc.– Has programmers and testers for executing detailed
tasks– May have config controller, db manager, etc
![Page 57: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/57.jpg)
57
Team structure..
• An alternative – democratic teams– Can work for small teams; leadership rotates
• Another one used for products– A dev team led by a dev mgr, a test team led by test
mgr, and a prog. Mgmt team– All three report to a product mgr– Allows specialization of tasks and separate career
ladders for devs, tests, PMs
![Page 58: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/58.jpg)
58
SCM process and planning
• Have discussed SCM process earlier• During planning, the SCM activities are planned
along with who will perform them• Have discussed planning also earlier
– Includes defining CM items, naming scheme, directory structure, access restrictions, change control, versioning, release procedure etc
![Page 59: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/59.jpg)
59
Quality Planning
![Page 60: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/60.jpg)
60
Quality Planning
• Delivering high quality is a basic goal• Quality can be defined in many ways• Current industry standard - delivered defect
density (e.g. #defects/KLOC)• Defect - something that causes software to
behave in an inconsistent manner• Aim of a project - deliver software with low
delivered defect density
![Page 61: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/61.jpg)
61
Defect Injection and Removal
• Software development is labor intensive• Defects are injected at any stage• As quality goal is low delivered defect density,
these defects have to be removed• Done primarily by quality control (QC) activities
of reviews and testing
![Page 62: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/62.jpg)
62
Defect Injection and Removal
Req.Analysis
Design R Coding R UT IT/ST AT
DevelopmentProcess
Defect Injection
R
Defect Removal
![Page 63: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/63.jpg)
63
Approaches to Quality Management
• Ad hoc - some testing, some reviews done as and when needed
• Procedural - defined procedures are followed in a project
• Quantitative - defect data analysis done to manage the quality process
![Page 64: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/64.jpg)
64
Procedural Approach
• A quality plan defines what QC tasks will be undertaken and when
• Main QC tasks - reviews and testing• Guidelines and procedures for reviews and
testing are provided• During project execution, adherence to the plan
and procedures ensured
![Page 65: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/65.jpg)
65
Quantitative Approach
• Goes beyond asking “has the procedure been executed”• Analyzes defect data to make judgements about quality• Past data is very important• Key parameters - defect injection and removal rates,
defect removal efficiency (DRE)
![Page 66: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/66.jpg)
66
Quality Plan
• The quality plan drives the quality activities in the project
• Level of plan depends on models available• Must define QC tasks that have to be
performed in the project• Can specify defect levels for each QC tasks (if
models and data available)
![Page 67: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/67.jpg)
67
Risk Management
![Page 68: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/68.jpg)
68
Risk Management
• Any project can fail - reasons can be technical, managerial, etc.
• Project management aims to tackle the project management aspect
• Engineering life cycles aim to tackle the engineering issues• A project may fail due to unforeseen events - risk
management aims to tackle this
![Page 69: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/69.jpg)
69
Risk Management
• Risk: any condition or event whose occurrence is not certain but which can cause the project to fail
• Aim of risk management: minimize the effect of risks on a project
![Page 70: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/70.jpg)
70
Risk Management Tasks
RISKMANAGEMENT
RISK ASSESSMENT
RISK IDENTIFICATION
RISK ANALYSIS
RISK PRIORITIZATION
RISK MANAGEMENTPLANNING
RISK RESOLUTION
RISK MONITORING
RISK CONTROL
![Page 71: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/71.jpg)
71
Risk Identification
• To identify possible risks to a project, i.e. to those events that might occur and which might cause the project to fail
• No “algorithm” possible, done by “what ifs”, checklists, past experience
• Can have a list of “top 10” risks that projects have seen in past
![Page 72: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/72.jpg)
72
Top Risk Examples
• Shortage of technically trained manpower• Too many requirement changes• Unclear requirements• Not meeting performance requirements• Unrealistic schedules• Insufficient business knowledge• Working on new technology
![Page 73: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/73.jpg)
73
Risk Prioritization
• The number of risks might be large• Must prioritize them to focus attention on the
“high risk” areas• For prioritization, impact of each risk must be
understood• In addition, probability of the risk occurring
should also be understood
![Page 74: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/74.jpg)
74
Risk Prioritization ...
• Risk exposure (RE) = probability of risk occurring * risk impact
• RE is the expected value of loss for a risk• Prioritization can be done based on risk
exposure value• Plans can be made to handle high RE risks
![Page 75: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/75.jpg)
75
A Simple approach to Risk Prioritization
• Classify risk occurrence probabilities as: Low, Medium, High
• Classify risk impact as: Low, Medium, High• Identify those that are HH, or HM/MH• Focus on these for risk mitigation• Will work for most small and medium sized projects
![Page 76: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/76.jpg)
76
Risk Control
• Can the risk be avoided?– E.g. if new hardware is a risk, it can be avoided by
working with proven hardware
• For others, risk mitigation steps need to be planned and executed– Actions taken in the project such that if the risk
materializes, its impact is minimal– Involves extra cost
![Page 77: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/77.jpg)
77
Risk Mitigation Examples
• Too many requirement changes– Convince client that changes in requirements will
have an impact on the schedule – Define a procedure for requirement changes– Maintain cumulative impact of changes and make it
visible to client– Negotiate payment on actual effort.
![Page 78: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/78.jpg)
78
Examples ...
• Manpower attrition– Ensure that multiple resources are assigned on key
project areas– Have team building sessions– Rotate jobs among team members– Keep backup resources in the project – Maintain documentation of individual’s work– Follow the CM process and guidelines strictly
![Page 79: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/79.jpg)
79
Examples ...
• Unrealistic schedules– Negotiate for better schedule– Identify parallel tasks– Have resources ready early– Identify areas that can be automated– If the critical path is not within the schedule, negotiate
with the client– Negotiate payment on actual effort
![Page 80: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/80.jpg)
80
Risk Mitigation Plan
• Risk mitigation involves steps that are to be performed (hence has extra cost)
• It is not a paper plan - these steps should be scheduled and executed
• These are different from the steps one would take if the risk materializes - they are performed only if needed
• Risks must be revisited periodically
![Page 81: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/81.jpg)
81
Project Monitoring Plans
![Page 82: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/82.jpg)
82
Background
• A plan is a mere document that can guide• It must be executed• To ensure execution goes as per plan, it must
be monitored and controlled• Monitoring requires measurements• And methods for interpreting them• Monitoring plan has to plan for all the tasks
related to monitoring
![Page 83: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/83.jpg)
83
Measurements
• Must plan for measurements in a project• Without planning, measurements will not be
done• Main measurements – effort, size, schedule,
and defects– Effort – as this is the main resource; often tracked
through effort reporting tools– Defects – as they determine quality; often defect
logging and tracking systems used
• During planning – what will be measured, how, tool support, and data management
![Page 84: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/84.jpg)
84
Project Tracking
• Goal: To get visibility in project execution so corrective actions can be taken when needed to ensure project succeeds
• Diff types of monitoring done at projects; measurements provide data for it
![Page 85: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/85.jpg)
85
Tracking…
• Activity-level monitoring– Each activity in detailed schd is getting done– Often done daily by managers– A task done marked 100%; tools can
determine status of higher level tasks
• Status reports– Generally done weekly to take stock– Summary of activities completed, pending– Issues to be resolved
![Page 86: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/86.jpg)
86
Tracking…
• Milestone analysis– A bigger review at milestones– Actual vs estimated for effort and sched is done– Risks are revisited– Changes to product and their impact may be
analyzed
• Cost-schedule milestone graph is another way of doing this
![Page 87: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/87.jpg)
87
Cost-schedule milestone graph
![Page 88: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/88.jpg)
88
Project Management Plan
• The project management plan (PMP) contains outcome of all planning activities - focuses on overall project management
• Besides PMP, a project schedule is needed– Reflects what activities get done in the project– Microsoft project (MSP) can be used for this– Based on project planning; is essential for day-to-day management– Does not replace PMP !
![Page 89: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/89.jpg)
89
PMP Structure - Example
• Project overview - customer, start and end date, overall effort, overall value, main contact persons, project milestones, development environment..
• Project planning - process and tailoring, requirements change mgmt, effort estimation, quality goals and plan, risk management plan, ..
![Page 90: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/90.jpg)
90
PMP Example ...
• Project tracking - data collection, analysis frequency, escalation procedures, status reporting, customer complaints, …
• Project team, its organization, roles and responsibility, …
![Page 91: 8 project planning](https://reader035.vdocument.in/reader035/viewer/2022062511/54bdb4374a7959a4658b4664/html5/thumbnails/91.jpg)
91
Project Planning - Summary
• Project planning forms the foundation of project management
• Key aspects: effort and schedule estimation, quality planning, risk mgmt., …
• Outputs of all can be documented in a PMP, which carries all relevant info about project
• Besides PMP, a detailed project schedule maintains tasks to be done in the project