Being completely new to PROMS-G meetings I found this an enthralling and enlightening experience. I am definitely hooked on the evidence of this meeting and its excellent audience, who actively participated throughout this journey of the dos and don'ts of project planning/estimating/measurement/control.

Andy’s key messages:

• If you don’t estimate then you can't measure, and definitely can't learn;
• Estimate is not a single couplet (elapsed time, cost) it’s a risk area around a trend line;
• Within an "estimate area" you should optimise the risk of not meeting time/cost goal;
• Application Size and the "Development Technology" determine time/cost trend line;
• Size and Technology are uncertain, hence the estimate risk area;
• Determine Size by comparison with past projects, hence need to measure and analyse;
• Determine Technology by reference to past experience of staff/tools/complexity;
• But above all else, document your project changes/additions/deletions and learn.

The above hardly does justice to Andy’s counsel; you really have to attend meetings to derive the full benefit of your PROMS-G membership.

Mike Tyrell

The speaker, Alan Langridge of Galorath, lead us through the fundamentals of software estimation and explained why this esoteric practice should be given greater attention. His recitation of the widely known statistics (from Standish-CHAOS studies) which show the very low percentage of projects that manage to deliver on time and budget, together with his re-stating of Brook's Law (from 'The Mythical Man Month' book) made a more than adequate demonstration of the need for project plans that are based on more accurate software estimation.

The first step in the process is to obtain an accurate size-estimate of the project. It was explained that this is done by any of the various methods of 'sizing-by-Proxy', such as 'size by Analogy' to a given software construct (e.g. the number of GUI Forms or web-pages in the project), Pairwise-Comparison-sizing to past projects, Function Point analysis or by a manual estimation of the number of Lines-of-Code. These values of size-estimate are then plugged into mathematical models, which are built (like the CoCoMo models) from statistical analysis of historical data from a number of past projects, to generate estimates for the effort (in man/months) and elapsed time needed to complete the work.

The mathematical models are tailored to a particular organisation's capabilities by specifying numerous input parameters that set such factors as the skill of the development personnel, productivity gains from the tools to be used, complexity of the project domain, and the maturity of the organisation's procedures. A particular feature of this mathematical model, with its inputs specified as 3-point estimates, is that it produces estimates for time and effort that cover a range of values, graded by their probability of success. It was explained that this is designed to help the Project Manager get an impression of the likelihood of completing on time, and provide him with the necessary information to help field the inevitable 'what-if' questions from his manager when asked to deliver the project sooner, or with fewer staff.

This was challenging subject matter, with a necessarily high degree of mathematical content, however the use of the model was carefully explained through a number of graphs that illustrated what trade-offs could be made between the different levels of effort to be employed on a project and the planned elapsed time for the project schedule.

The audience were keen to understand how they could apply these techniques to their own work and if it might be applicable to other areas of the IT industry such as system implementation and deployment. It was explained that models for other parts of the IT industry are currently under investigation.

Overall, an insightful seminar on an interesting subject.

Steven Bishop