Previously we talked about Planning and Estimation. These estimation techniques are traditionally used at the beginning of a project, but are immensely useful as periodic techniques for measuring progress.

We observed that during the generation process, we also create errors, whose correction is a generation process and so on. In good programmes this recursion is finite, and measurement of the number and rate of iterations, and their place relative to plan, can provide us with key progress and  process indicators.

By observing the number of versions of a component generated (information drawn from the version control system) and relating it to the (programme plan) planned timing, you can understand when errors are being detected/corrected. If this has more iterations than you expect, the component may be too complex or the developer immature, say. If those iterations occur later than the plan, then the component development may be running late, or be insufficiently tested (which may be a fault of either development or test environment).

These trigger signal can usefully lead us to investigate the component, the development /test environments or the skills of the members of the team. If several components are assigned to the same team members the skill association may be evident; if all components, irrespective of team members, show the same propensity for iteration rates then it is likely the processes or environment is inadequate.

Software programme management is about identifying and fixing root causes of deviation to programme, rather than just about progress chasing. The manufacturing stages of software engineering are its processes and a careful watch should be maintained on both input quality and output as a measure of the process’ efficacy. Resource levels, skill requirements and lean processes are outputs from running a software programme that can be re-used as seed for a new programme, or for ensuring realistic planning of the programme.

Earlier we showed that understanding where errors should be detected is key to planning. For instance, a self-contained component with a simple interface (e.g. a Maths function), would expect to be error free very close to generation; A message transport protocol, that relies on the interaction of 2 different pieces of hardware, and a series of lower level protocol stacks, is unlikely to be error free until significant system test.

Early development effort (in creation of error free components) should major on ‘infrastructure’, i.e. the primitive components and functions that are used by all other features. Failing to sufficiently test these components may seriously hamper future progress at higher levels of application.

Having a ‘slick’ change mechanism, that is suitably controlled, makes the development productive and efficient. No other process stage needs as much effort at being lean. Instrumenting this change process will provide all the valuable information from which the above metrics can be extracted and compared with the ‘expectation’ implied in the plan.

Careful control is required to differentiate causes of change, e.g. internal due to errors in implementation, refactoring due to not being able to accommodate a previously unaddressed requirement, or externally driven change. All will impact your development effort, but the project manager should have contingencies for the first two and be able to negotiate cost, programme etc changes for the last (even if still internal!). No change is for free, even scope reduction can cost money in a programme in which design effort has already been expended.

Now all you have to do is convince the business that your estimates and contingency are correct, including a statement on the assumed requirement that is addressed, and defensible, by reference to previous metrics and adjustments for the success or lack thereof on previous programmes.

Finally, it is never acceptable to arbitrarily cut costs or programme duration without a commensurate change in scope, skill capacity and capability, or risk.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.     ___________________________________________________________________________