Sqp 2005 L7 Large Systems

Best-Practices for Managing Large Projects Geoff Dromey Software Quality Institute

© R.G.Dromey, Griffith University, 2005

Reference      

N.Brown,  Industrial  Strength  Management  Strategies,  IEEE  Software, July 1996,95­103 

•  As software systems become larger  defects become more of a problem 

Large Systems CLAIM:  •  The  number  of  defects  occurring  in  delivered  software  increases  exponentially  with  the  size  of  the  system being built     FACT:  •  The  US  DoD  spends  $42  billion  annually  for  the  development  and  maintenance  of  its  computer  systems ­ only $7 billion of this sum  buys hardware 

Large Systems •  The  demand  to  build  large­scale  software systems keeps growing.     •  Unfortunately  the  ability  to  the  development  of  these  systems  has  not  kept pace. 

Problems With Large Systems •  Frequently  the  true  nature  and  pervasive  extent  of  underlying  project  problems  remain  invisible  to  project  managers until it is too late.    •  Furthermore  as  software  systems  become larger defects become a much  more significant problems.    •  These are today's realities in software        engineering.

The Root Cause of the Problem •  Major  problems  seem  to  be  management  rather  than  technical  problems. (F.P.Brooks)     •  There  is  plenty  of  good  advice  and  lessons that have been learned that are  around  but  these  things  tend  to  be  ignored.   

The Root Cause of the Problem •  Brown claims there are no silver bullets  and  chasing  them  postpones  real  improvement    •  Senior  management's  lack  of  understanding  leads  to  unwillingness  to  support  the  needed  training,  tools,etc  ­  this  frequently  undermines  software teams and projects 

Software Management Framework (1) •  To  contain  complexity  nine  principal  best practices have been suggested.    •  These  practices  constitute  a  control  mechanism  for  large  projects.  These  practices focus on:      ­  Identifying  and  correcting  defects   and  potential  problems  early.  The   longer  a  defect  remains  in  a  system   the more it costs to fix it. 

Software Management Framework (2)

• Planning and estimation.   Measuring  progress against a   planned  set  of  accomplishments   delivers  an  effective  measure of   progress achieved  

Software Management Framework (3) •  Minimize  rework  caused  by  uncontrolled  change.  Uncontrolled  change  causes  chaos.  Systematic  use  of  problem  reports,  change  control,  engineering change proposals and cost  and  schedule  baselines  is  essential  to  controlling change. 

Software Management Framework (4) •  Make  Effective  Use  Of  People.  The  single most important determinant of a  project's  success  is  the  ability,  experience,  and  motivation  of  its  people.  The  great  challenge  is  in  retaining  and  motivating  competent  people 

Nine Principal Best-Practices          

1.

Formal Risk Management  

2.

Agreement on Interfaces.  

3.

Formal Inspections. 

4. Metric­based Scheduling           & management 

         

Nine Principal Best-Practices 5.   Binary Quality Gates at Inch­Pebble          Level  6.   Program­wide visibility of progress          vs plan  7.   Defect tracking against quality          targets  8.   Configuration management 

9.   People­aware Management             accountability 

Practice 1: Formal Risk Management •  Experience  with  large  projects  has  shown  that  managing  risk  is  one  of  the most critical things    •  All software development has risk.     •  The  cost  of  resolving  risk  early  is  usually  relatively  low,  but  it  increases  dramatically  as  the  project progresses.   

Practice 1: Formal Risk Management •  Despite  this  advice  on  many  projects  only  lip  service  is  paid  to  managing risk.    •  Effective  risk  management  requires  commitment  of  resources,  use  of  rigorous  methods,  for  identifying,  monitoring and managing risk. 

Practice 1: Formal Risk Management •  Must  appoint  senior  team  member  as Risk Officer.    •  Must  identify  and  store  in  database  all non­negligible risks.     •  Each  risk  should  be  characterized  by its probability of occurrence and  by its consequence   

Practice 1: Formal Risk Management •  Must  plan  for  and  mitigate  risk  by  keeping  risk  items  off  the  critical  path through early identification and  workarounds.     •  Unresolved  risk  items  should  be  tracked  and  should  estimate  probable  cost  for  unresolved  risk  versus risk reserve remaining.   

Practice 1: Formal Risk Management •  Plan risk­item resolution as early as  possible.  Include  a  calculated  risk  reserve  of  time,  money,  and  other  key resources to deal with risks that  materialize unexpectedly.     •  Provide  frequent  risk  status  reports  to the project manager ­ focus on:         Top ten unresolved risks on          the critical path.  

Practice 1: Formal Risk Management

•  Also include details of:      ­  risks resolved since last time,        ­  new risk items since last report        ­  probable cost of unresolved          risk versus risk reserve 

Practice 1: Formal Risk Management •  Set  up  an  anonymous  reporting  mechanism  to  allow  staff  to  report  on risks.    •  Help  foster  a  "no  cover­up  culture"  in relation to risk.    •  The importance of managing risk on  any  large  project  should  never  be  underestimated.    •  As  one  experienced  project  manager  said:  "If  you  are  not  managing risk you are managing the  wrong thing". 

Practice 2: Agree on Interface Upfront

•  A  critical  success  factor  for  large  projects  is  to  give  initial  priority  to  settling  systems  interface  issues  at  the outset.