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.