Software Project Management

RISK MANAGEMENT, COMMUNICATION

MANAGEMENT, CHANGE MANAGEMENT &
QUALITY MANAGEMENT
  Risk  Management  

2  
Risk Management

3  
 Importance of Project Risk Management

  The  art  and  science  of  iden.fying,  analyzing,  and  

responding  to  risk  throughout  the  life  of  a  project  
and  in  the  best  interests  of  mee:ng  project  
objec:ves  

  Risk  management  is  o=en  overlooked  in  projects  

4  
Benefits from Software Risk
Management Practices*

*Source:  Kulik  and  Weber,  KLCI  Research  Group   5  

 Risk Can Be Negative &
Positive
  Nega:ve  risk:    understanding  poten:al  problems  
that  might  occur  in  the  project  and  how  they  might  
impede  project  success  

  Posi:ve  risks:  risks  that  result  in  good  things  

happening  (opportuni:es)  

6  
 Risk Utility
  Risk  u.lity  or  risk  tolerance  is  your  willingness  to  
accept  or  avoid  risk.  

What  is  your  risk  

tolerance?  

7  
 Project Risk Management
Processes
 It  is  all  about  planning  
◦ Planning  risk  management  
◦ Iden.fying  risks  
◦ Performing  qualita.ve  risk  analysis  
◦ Performing  quan.ta.ve  risk  analysis  
◦ Planning  risk  responses  
 Controlling  and  Monitoring  
◦ Controlling  risk  

8  
 Planning Process Group:
Planning Risk Management
  The  main  output  of  this  process  is  a  risk  
management  plan—a  plan  that  documents  the  
procedures  for  managing  risk  throughout  a  project  
  Key  Parts  to  Plan:  
◦ Budget  and  schedule  
◦ Risk  categories  
◦ Risk  probability  and  impact  
◦ Revised  stakeholders’  tolerances  
◦ Tracking  

9  
 Contingency and Fallback
Plans, Contingency Reserves
  Con.ngency  plans:  are  predefined  ac:ons  that  the  project  
team  will  take  if  an  iden:fied  risk  event  occurs  
  Fallback  plans:  are  developed  for  risks  that  have  a  high  
impact  on  mee:ng  project  objec:ves,  and  are  put  into  
effect  if  a[empts  to  reduce  the  risk  are  not  effec:ve  
  Con.ngency  reserves  or  allowances:  are  provisions  held  by  
the  project  sponsor  or  organiza:on  to  reduce  the  risk  of  
cost  or  schedule  overruns  to  an  acceptable  level;  
  Management  reserves:  are  funds  held  for  unknown  risks  

10  
 Common Sources of Risk in IT
Projects
Success Criterion Relative Importance
The  Standish  Group  
User Involvement 19
developed  an  IT  
success  poten:al   Executive Management support 16
scoring  sheet  based   Clear Statement of Requirements 15
on  poten:al  risks   Proper Planning 11
Realistic Expectations 10
Smaller Project Milestones 9
Competent Staff 8
Ownership 6
Clear Visions and Objectives 3
Hard-Working, Focused Staff 3
Total 100

11  
 Broad Categories of Risk
  Market  risk  

  Financial  risk  

  Technology  risk  

  People  risk  

  Structure/process  risk  

12  
 Risk Breakdown Structure
  A  risk  breakdown  structure  is  a  hierarchy  of  poten:al  risk  
categories  for  a  project  

  Similar  to  a  work  breakdown  structure  but  used  to  iden:fy  

and  categorize  risks  

13  
Potential Negative Risk Conditions
Associated With Each Knowledge Area

14  
 Planning Process Group: Identifying Risks
  Iden.fying  risks  is  the  process  of  understanding  what  
poten:al  events  might  hurt  or  enhance  a  par:cular  project  
  Goal:  understanding  what  are  the  risk  that  could  poten:ally  
influence  the  project  and  document  their  characteris:cs  
  Risk  iden.fica.on  is  an  itera.ve  process  (new  risks  may  be  
iden:fied  as  the  project  progresses;  old  risks  may  become  
“obsolete”)  
   
Output:  Risk  Register,  basis  for  qualita:ve/quan:ta:ve  risk  
analysis    
 
15  
 Risk Register
  A  risk  register  is:  
◦ A  document  that  contains  the  results  of  various  risk  management  
processes  and  that  is  o=en  displayed  in  a  table  or  spreadsheet  
format  
◦ A  tool  for  documen:ng  poten:al  risk  events  and  related  informa:on  

  Risk  events  refer  to  specific,  uncertain  events  that  may  

occur  to  the  detriment  or  enhancement  of  the  project  

16  
Risk Register Contents
§ An  iden:fica:on  number  for  each  risk  event  
§ A  rank  for  each  risk  event  
§ The  name  of  each  risk  event  
§ A  descrip:on  of  each  risk  event  
§ The  category  under  which  each  risk  event  falls  
§ The  root  cause  of  each  risk  
§ Triggers  for  each  risk;  triggers  are  indicators  or  symptoms  of  actual  
risk  events  
§ Poten:al  responses  to  each  risk  
§ The  risk  owner  or  person  who  will  own  or  take  responsibility  for  each  
risk  
§ The  probability  and  impact  of  each  risk  occurring.  
§ The  status  of  each  risk  

17  
 Planning Process Group:
Performing Qualitative Risk Analysis

  Assess  the  likelihood  and  impact  of  iden:fied  risks  

to  determine  their  magnitude  and  priority  
  Risk  quan:fica:on  tools  and  techniques  include:    
◦ Probability/impact  matrixes  
◦ The  Top  Ten  Risk  Item  Tracking  
◦ Expert  judgment  

18  
 Probability/Impact Matrix
  Probability  of  risk  occurring  by  impact  of  risk  

19  
 Probability/Impact Matrix: Risk
Factors
Numbers  that  
represent  the  overall  
risk  of  specific  events  
based  on  their  
probability  of  
occurring  and  the  
consequences  to  the  
project  if  they  occur  

20  
 Top Ten Risk Item Tracking

  Top  Ten  Risk  Item  Tracking  is  a  qualita.ve  risk  analysis  

tool  that  helps  to  iden:fy  risks  and  maintain  an  awareness  
of  risks  throughout  the  life  of  a  project  

21  
 Watch List
 A  watch  list  is  a  list  of  risks  that  are  low  
priority,  but  are  s:ll  iden:fied  as  poten:al  
risks  
◦ Qualita:ve  analysis  can  also  iden:fy  risks  that  
should  be  evaluated  on  a  quan:ta:ve  basis  

22  
Planning Process Group:
Performing Quantitative Risk Analysis
  Large,  complex  projects  (or  risks)  involving  leading  
edge  technologies  o=en  require  extensive  
quan.ta.ve  risk  analysis  
  Main  techniques  include:  
◦ Decision  tree  analysis  
◦ Simula:on  
◦ Sensi:vity  analysis  

23  
 Quantitative Technique: Decision Trees
and Expected Monetary Value
  A  decision  tree  is  a  diagramming  analysis  technique  used  
to  help  select  the  best  course  of  ac:on  in  situa:ons  in  
which  future  outcomes  are  uncertain  

24  
Quantitative Technique:
Simulation
  Simula:on  uses  a  representa:on  or  model  of  a  
system  to  analyze  the  expected  behavior  or  
performance  of  the  system  

25  
Planning Process Group:
Planning Risk Responses
 A=er  iden:fying  and  quan:fying  risks,  you  
must  decide  how  to  respond  to  them  
 Four  main  response  strategies  for  nega:ve  
risks:  
◦ Risk  avoidance  
◦ Risk  acceptance  
◦ Risk  transference  
◦ Risk  mi:ga:on  

26  
General Risk Mitigation Strategies for
Technical, Cost, and Schedule Risks

27  
 Response Strategies for
Positive Risks
  Risk  exploita:on  
  Risk  sharing  
  Risk  enhancement  
  Risk  acceptance  

28  
 Monitoring/Controlling Process Group: Controlling
Risks
  Responding  to  risk  events  and  ensuring  that  risk  
awareness  is  an  ongoing  ac:vity    
◦ Workarounds  
  Main  outputs  of  risk  control  are:  
◦ Work  performance  informa:on  
◦ change  requests  
◦ updates  to  the  project  management  plan,  other  
project  documents,  and  organiza:onal  process  
assets  

29  
COMMUNICATION MANAGEMENT
Importance of Good
Communications
Communica:on  Paths  Between  a  Project’s  Par:es-­‐
At-­‐Interest  

31  
Keys to Good Communications

  ~80-­‐90%  of  a  PM’s  :me  spent  communica:ng  

◦ Focus  on  needs  –  both  group  and  individual  
◦ Mix  methods  -­‐  formal  and  informal    
◦ Set  the  stage  for  communica:ng  bad  news  
  Distribute  important  informa:on  in  an  effec:ve  
and  :mely  manner  
  Determine  the  number  of  communica:on  channels  

32  
 Communications Channels
  As  the  number  of  people  involved  increases,  the  
complexity  of  communica:ons  increases  because  
there  are  more  communica:ons  channels  or  
pathways  through  which  people  can  communicate.  

  Number  of  communica:ons  channels  =  n(n-­‐1)  

                                                               2        
where  n  is  the  number  of  people  involved  

33  
Communications Management
Plan Contents
1. Stakeholder  communica:ons  requirements  
2. Suggested  methods  or  technologies  for  
conveying  the  informa:on  
3. Escala:on  procedures  for  resolving  issues  
4. Revision  procedures  for  upda:ng  the  
communica:ons  management  plan  
5. A  glossary  of  common  terminology  

34  
Sample Stakeholder Analysis for Project
Communications

INFORMATION  TECHNOLOGY  PROJECT  MANAGEMENT,  SEVENTH  EDITION   35  

Communication Technology
Determination
  Factors  contribu:ng  to  determining  the  
communica:on  technology  to  be  used:  
◦ Availability  
◦ Project  environment  
◦ Project  Length  
◦ Urgency  
◦ Prepara:on  Level  

36  
Importance of Face-to-Face
Communication
Communica:on  needs  to  be  adjusted  depending  on  
the  channel  
How  should  you  approach  communica:on    

Short,  frequent  mee:ngs  are  o=en  very  effec:ve  in  

IT  projects  

37  
Managing Communications
 Managing  communica:ons  is  a  large  part  of  
a  project  manager’s  job  

 Important  considera:ons  include:  

◦ Technology  
◦ Appropriate  methods  and  media  to  use  
◦ Performance  repor:ng  

38  
Classifications for Communication Methods

  Interac+ve  
  Push    
  Pull    

39  
 Distributing Information in an
Effective and Timely Manner
§Don’t  bury  crucial  informa:on  

§Don’t  be  afraid  to  report  bad  informa:on  

§Oral  communica:on  via  mee:ngs  and  informal  talks  

helps  bring  important  informa:on—good  and  bad—out  
into  the  open  

40  
Reporting Performance
     Performance  repor:ng  keeps  stakeholders  
informed  about  how  resources  are  being  
used  to  achieve  project  objec:ves  
◦ Status  reports  
◦ Progress  reports  
◦ Forecasts  

41  
 Controlling
Communications
  The  main  goal  of  controlling  communica:ons  is  to  ensure  
the  op:mal  flow  of  informa:on  throughout  the  en:re  
project  life  cycle  

  The  project  manager  and  project  team  should  use  their  

various  repor:ng  systems,  expert  judgment,  and  mee:ngs  
to  assess  how  well  communica:ons  are  working.    
◦ If  problems  exist,  the  project  manager  and  team  need  to  take  
ac:on,  which  o=en  requires  changes  to  the  earlier  processes  
of  planning  and  managing  project  communica:ons  

42  
Suggestions for Improving
Project Communications
  Develop  be[er  communica:on  skills  

  Run  effec:ve  mee:ngs  

  Use  e-­‐mail  and  other  technologies  effec:vely  

  Use  templates  for  project  communica:ons  

43  
 Developing Better
Communication Skills
  Most  companies  spend  a  lot  of  money  on  technical  
training  for  their  employees,  even  when  employees  
might  benefit  more  from  communica:ons  training  
 
  It  takes  leadership  to  improve  communica:on  

44  
 Running Effective Meetings
  Determine  if  a  mee.ng  can  be  avoided  
  Define  the  purpose  and  intended  outcome  of  the  
mee:ng  
  Determine  who  should  aKend  
  Provide  an  agenda  before  mee.ng  
  Set  the  ground  rules  for  the  mee:ng  

45  
 Using E-Mail, Instant Messaging, Texting, and
Collaborative Tools Effectively

  Make  sure  that  e-­‐mail,  instant  messaging,  tex:ng,  

or  collabora:ve  tools  are  an  appropriate  medium  
for  what  you  want  to  communicate    

  Be  sure  to  authorize  the  right  people  to  share  and  

edit  your  collabora:ve  documents  

46  
Other Communication
Considerations
  Rarely  does  the  receiver  interpret  a  message  
exactly  as  the  sender  intended  

  Geographic  loca:on  and  cultural  background  affect  

the  complexity  of  project  communica:ons  
◦ Different  working  hours  
◦ Language  barriers  
◦ Different  cultural  norms  

47  
 Using Templates for Project
Communications
  Many  technical  people  are  afraid  to  ask  for  help  
  Providing  examples  and  templates  for  project  
communica:ons  saves  :me  and  money  
  Organiza:ons  can  develop  their  own  templates,  use  some  
provided  by  outside  organiza:ons,  or  use  samples  from  
textbooks  

  Recall  that  research  shows  that  companies  that  excel  in  

project  management  make  effec:ve  use  of  templates  

48  
 Lessons Learned Reports
& Archives
  The  project  manager  and  project  team  members  
should  each  prepare  a  lessons-­‐learned  report  

  Project  archives  are  a  complete  set  of  organized  

project  records  that  provide  an  accurate  history  of  
the  project  
◦ These  archives  can  provide  valuable  informa:on  for  
future  projects  as  well  

49  
CHANGE AND CONFIGURATION
MANAGEMENT
Change and Configuration
Management

51  
 Introduction
  Change  Control  is  the  set  of  prac:ces  to  ensure  
request  for  changes  are  properly  taken  care  of  
   Configura.on  Management  is  the  set  of  prac:ces  to  
ensure  project  outputs  remain  coherent  over  :me!  
   Change  Control  and  Configura:on  Management  span  
over  the  lifecycle  of  the  project  outputs  
   In  so=ware  projects  ar:facts  are  extremely  simple  to  
change  (e.g.,  edi:ng  a  file)  
   In  so=ware  projects,  connec:on  with  bug  repor:ng/
bug  lifecycle  

52  
Causes for Request for
Changes
Incompleteness  or  incoherencies  in  the  project  
requirements  or  in  the  descrip.on  of  work  
A  beKer  comprehension  of  the  system  to  be  
developed  
A  technical  opportunity  
A  technical  challenge  
A  change  in  the  external  environment  
Non-­‐compliance  of  a  project  deliverable  

53  
A Change Control Process

54  
 A Change Control Process
A change control board might be appointed to
approve/reject changes
 

The cost and risk of changes increase as the project

moves to the delivery
 

The process ensures a formal record is kept and and a clear

procedure is set to evaluate the impact of changes
 

Change and change management is embraced by agile

methodologies (changes “treated” as requirements)

55  
 Configuration Management
Goals
  Being  able  to  build  a  system  from  a  consistent  set  of  
components  
  Being  able  to  retrieve  a  so=ware  component  when  
needed  (consider:  storage  :me,  storage  means)  
  Being  able  to  view  the  history  of  changes  a  system  
has  undergone  
  Being  able  to  retrieve  a  previous  version  of  a  system  
     

56  
 Steps & Tools: Establish
Baseline
The  first  step  is  “establishing  what  a  product  is”  
A  good  CM  requires  to:  
◦ Clearly  iden:fy  the  items  which  cons:tute  a  product  
◦ Iden:fy  the  rela:onships  among  these  items  
◦ Choose  an  appropriate  iden:fica:on  and  numbering  
scheme  for  versions  
◦ Take  “snapshots”:  baseline  records  

57  
 Steps & Tools:
Management Changes
The  second  step  is  “maintaining  coherency  over  
:me”  
A  good  CM  process  requires  to:  
◦ Define  the  “baseline  record”  (the  star:ng  point)  
◦ Iden:fy  and  approve  requests  for  changes  (see  change  
control)  
◦ Formally  record  changes  and  history  of  each  item  
◦ Maintaining  old  versions  
  For  family  of  products  there  could  be  different  baselines.  Changes  might  
need  to  be  applied  to  one  or  more  baseline  (consider  a  security  fix  to  a  
browser)  

58  
Versions Control Systems –
Main Concepts

59  
 Version Control Systems –
Main Concepts
  In  the  simple  case  (early  VCS)  each  file  would  have  
an  independent  repository  
  Coherence  is  kept  by  assigning  the  same  tags  to  all  
ar:facts  cons:tu:ng  a  baseline  
  More  recent  VCS  manage  sets  of  ar:facts  in  an  
integrated  way  
  Tagging  is  used  to  mark  important  baseline  records  
  A  VCS  typically  support  parallel  access  and  edi:ng  
of  ar:facts  

60  
QUALITY MANAGEMENT
Quality Management

62  
Software Quality Assurance
  SoOware   quality   assurance   is   the   planned   and  
systema:c   applica:on   of   ac:vi:es   to   ensure  
conformance   of   soDware   life   cycle   processes   and  
products   to   requirements,   standards,   and  
procedures.  
 

63  
 Software Quality Assurance, Cont’d
  The  defini:on  applies  both  to  the  process  and  the  
products  
  Quality  assurance  (like  many  other  ac:vi:es)  is  
planned  and  systema:c  
  Conformance  is  required  w.r.t.  all  the  elements  
characterizing  the  so=ware  opera:onal  
environment  

64  
 Quality Assurance Process
Quality  planning,  which  iden:fies  the  relevant  
standard  and  prac:ces  and  the  way  to  
implement  them  
Quality  assurance,  which  focuses  on  ensuring  
that  the  project  applies  and  follows  the  quality  
standards  iden:fied  at  the  previous  step  
Quality  control,  which  ensures  that  the  
products  respect  the  quality  standards  iden:fied  
during  the  planning  phase  

 
65  
 Quality Planning
  Goal:  ensure  the  goals  of  quality  management  are  met  in  
a  project  
  Means:  
◦ Iden:fica:on  of  constraints  and  quality  goals  in  scope  
◦ Iden:fica:on  of  standards  and  procedures  to  be  
applied  
◦ Iden:fica:on  of  techniques  to  be  applied  
◦ Alloca:on  of  resources  (:me,  people,  budget)  to  
quality  assurance  ac:vi:es  
◦ Roles  and  responsibili:es  
Output:  quality  assurance  planning  document  
 

66  
 Quality Planning, Cont’d
  Quality  needs  to  be  balanced  with  the  other  project  
constraints  (e.g.  :me  and  costs)  
  Not  all  systems  are  equally  cri:cal:  NASA,  for  instance  
dis:nguishes  eight  different  classes  of  so=ware  
systems  
  The  quality  assurance  team  should  be  independent  
from  the  development  team  
  Different  “levels”  of  independence:  
◦ different  roles  in  the  project  
◦ different  structures  in  the  organiza:on  
◦ independent  organiza:ons  
 

67  
 Quality Assurance
  Goal:  ensure  that  the  project  applies  and  follows  
the  quality  standards  
  Main  tool:  quality  audits  
  Triggers:  :me,  milestones,  or  cri:cal  events  in  the  
project  (according  to  the  quality  plan)  
  Quality  audits  include  
◦ Inspec:ons  
◦ Reviews  
◦ Walkthroughs  
  Output:  Main  findings  and  recommenda:ons  
 

68  
Signs of Troublesome Projects
 Frequent  changes  in  milestones  
 Unexplained  fluctua:ons  in  personnel  
 Con:nued  delays  in  so=ware  delivery  
 Unreasonable  number  of  non  conformance  
reports  or  change  requests.  
 

69  
 Quality Control
  Goal:  ensure  that  the  products  respect  the  quality  
standards  iden.fied  during  the  planning  phase  
  Main  tools:  
◦ Inspec:ons  
◦ Analyses  
◦ Tes:ng  
  Triggers:  milestones  or  cri:cal  events  in  the  project  
(according  to  the  quality  plan)  
  Output:  List  of  non-­‐conformance  reports  
  70  
 Quality Control, Cont’d
  Quality  control  of  so=ware  systems  is  extremely  difficult,  
because:  
◦ of  the  enormous  number  of  states  a  so=ware  system  can  be  in  
(exhaus:ve  tes:ng  is  imprac:cal/impossible)  
◦ the  opera:ng  environment  is  unpredictable  
◦ discon:nuity:  li[le  changes  in  inputs  can  cause  enormous  changes  in  
outputs  
◦ non  func:onal  requirements  can  be  difficult  to  assess  (consider,  e.g.,  
maintainability,  usability)  
◦ test  automa:on  can  be  difficult  or  very  costly  (consider,  e.g.,  tes:ng  
a  GUI)  
◦ today’s  systems  are  composed  by  using  different  technologies  (e.g.,  
HTML/CSS,  Javascript,  PHP,  WebServer,  OS)  

  71  
 Quality Control, Cont’d
  Walkthroughs  and  code  inspec.ons:  
◦ the  system  is  analyzed  by  an  independent  team  

   Analyses:  
◦ sta:c  checkers  verify  the  correct  use  of  certain  syntac:c  constructs  (e.g.,  no  
assignments  in  condi:ons)  
◦ dynamic  checkers  verify  anomalies  and  suspect  situa:ons  by  execu:ng  
instrumented  code  
◦ code  metrics  are  collected  to  measure  other  quality  characteris:cs  (e.g.,  
comments/lines;  unit  test  coverage)  
◦ formal  verifica:on  (theorem  proving,  model  checking)  proves  proper:es  
about  abstract  representa:ons  of  the  system  
Tes.ng:  
◦ tests  are  performed  on  a  system  to  verify  the  behavior  under  specific  
circumstances  

  72  
 Establishing a Metrics Program
  A  metrics  collec.on  program  quan:ta:vely  assesses  how  the  project  
goals  are  being  achieved  
  Process  metrics:  measure  different  characteris:cs  of  a  project  
  Product  metrics:  measure  different  characteris:cs  of  a  project  product  
  Trends  o=en  more  important  than  point-­‐wise  numbers  
  Be[er  if  automated  
     
     
     

 
73  
  
 
 

End  of  the  Lectures  

 
Thank  You!    

74