1. deadlines: delivering software dependably to schedules (and preferably, with short lead times)
    
2. quality: software delivered to customers is with known levels of completeness and quality (eg. freedom from defects), and accurately meets its functional and performance requirements

In other words, software organisation wants to be confident that the software delivered to customers is of a quality that meets customer expectations and is done within budget; no unpleasant surprises for anyone!

A Real-Life Example
The diagram below gives a high level view of a software design, development and delivery process we developed and implemented with a client organisation - a commercial software house developing large-scale, off-the-shelf software component products for sale to the financial services market.

In this example, the software house had a well-deserved reputation as a technology leader and had very capable technical staff. However, the organisation's difficulties were in servicing its customers. Despite a lot of effort, the organisation was finding it practically impossible to work to any timetable for delivering software with complete functionality.

Deadlines were being missed and the product development plans were slipping month-by-month. The software was functionally complex and the organisation found it difficult to have well-founded confidence in the completeness, stability or freedom from defects (quality) that it did produce for customers.

The process described below was developed over a number of months to address the shortcomings of the situation. The technical staff adapted well to the working practices embedded in the process.

The process itself provided the basis for close management of every stage of the end-to-end development stages. We were able to establish and operate a management system which enabled regular, dependable planning and scheduling of the development process and activities. Within a few months, the delivery cycle was reliably and regularly delivering high quality software, to 2-weekly published delivery schedules

Development Process for dependably meeting Customer Deadlines
There are some comments to make on implementing and operating this kind of process in a software development organisation.

The diagram below shows software architectural design work being released - at the left hand end - into a stage-by-stage process through which each scheduled piece of development work passes.

Each piece of work was planned, by backwards scheduling from required completion dates, taking resource constraints, task dependencies and process choke-points into account. The completion dates represented the deadlines required for release and shipment to a customer of a tested and packaged piece of software.

The process was designed with the express purpose of meeting scheduled completion deadlines, with required quality and within resource constraints. In this particular case, we found that a release of completed software every 2 weeks, for shipment to the customer, was a realistic and acceptable service level for the software house and its customers. (Prior to our engagement, the organisation had been unable to meet delivery schedules and software which was released, was of an unknown quality and completeness).

Software Delivery Process: Incorporates rigorous Inspection at Review Points to improve process delivery performance.
 

It also shows which people were involved in the reviews at each stage. All of those involved received training in Inspection so that they understood what was expected of them, and how to play their roles.

The various stages in the software delivery process shown in the diagram refer to something called 'Entry-Points'. Entry-Points (which in effect are interfaces) were key features in the kind of software this particular organisation developed.

As we developed the process, it became evident that we could subdivide the software work around the delivery of entry-point functionality. For scheduling purposes, we needed some form of basic unit we could use as the basis of our planning. We needed something that was meaningful and useful to deliver to customers, but was small enough so that it wouldn't take many weeks or months before there was evidence we were being productive. We chose entry-points as a meaningful unit of functionality that would be recognised by the company's customers as useful to them.

However, that doesn't mean initially it was an obvious unit around which to develop our process - it wasn't. We had to do some thinking and experimenting. You may also need to experiment but your software will probably have some equivalent features, the existence of which can help you define meaningful sub-deliverables around which you can devise a delivery process to give you increased levels of management control.

The process in the diagram has checkpoints built-in. The checkpoints use both Document Inspection and Reviews. The combination of these two (very different) techniques dramatically reduces the amount of rework that has to be performed downstream (where 'downstream' refers to the right hand side of the diagram) to rectify defects/mistakes introduced by upstream (left hand side of the diagram) activities.

Reducing rework has a number of significant benefits. Namely: -

• reduces cycle times through the process (by avoiding extended working times and not blocking the progress of other work);
   
• reduces costs (by increasing productivity of staff - who aren't diverted onto rework - and thereby avoiding extra staffing);
   
• avoids the backwards-and-forwards between process stages when problems are returned to earlier stages, which tends to break down the designed divisions between process stages... which makes dependable scheduling very difficult;
   
• eliminates a significant source of variability in the time needed to complete each task. Variability messes up the reliable scheduling of work completion - which also leads to impacts on availability of resources for working on other tasks.

Again to reduce the variability - and increase the predictability of task times within the process, it's important to control the introduction of new work into the process. Accordingly, a work release-point is shown at the left hand side of the diagram which provides a mechanism for keeping the workloads and resource utilisations inside the process within pre-defined limits and avoiding overloads. Overloads will always wreck a delivery schedule!

The nature of the process provided visibility of the work in progress and allowed planning of tasks and workloads for each of the stages of of the process to meet the overall completion schedules. That in turn provides a baseline for monitoring of the progress of work throughout the process and gives early warning if a particular piece of work is at risk of failing to meet its final scheduled completion.

Key Points

• The initial problem for the software house was how to meet its commitments to customer with high quality software delivered to agreed schedules?
   
• Given the backlog in the software development schedule, it wasn't possible or realistic to try to rework everything and deliver all the software promised, all at once.
   
• What we were able to to was devise a process (outlined in the diagram) by which we could make useful deliveries of software to customers of software with assured quality and to dependable delivery dates. We negotiated that approach with customers who accepted it because at least they were starting to receive their first deliveries of useful software
   
• A 2-weekly delivery cycle was adopted. We found that planning to deliver units of useful, quality and tested software every 2 weeks was a pattern we could stabilise the whole operation. The staff became very good at working to that cycle.
   
• The 'build-process' had been the victim of frequent failures and one of the early steps was to stabilise it by eliminating the various causes of its instability.
   
• The process was developed to address the specific commercial and technical needs of this software house. It worked. We didn't concern ourselves with what CMM/CMMI or other generic methodologies would stipulate. We needed to improve the technical and commercial results urgently, rather than comply with published models.

The key techniques and approaches used...

• Software Inspection (also known as Document Inspection) at each critical stage in the process
   
• Training in Document Inspection for all those who would participate in the Inspection sessions (the staff were already perfectly competent developers, business analysts, test specialists, etc)
   
• The team also received training in writing rigorous requirements specifications, design documents and test plans although our experience was that simply by subjecting key documents to inspection, a shared understanding of the quality levels required in documents developed on its own accord (which is a key learning point in applying rigorous inspection).
   
• The process stages allowed the flow of work and resource types needed to do the work to be defined in a scheduling model. The scheduling model, based on Critical Chain concepts, was a simplified version of the scheduling approach we used in the management control of work flow within Laboratories (more...).
   
• The scheduling model was simple but effective. It allowed us to plan the end-to-end delivery cycle without overloading what ever resource or stage had become the current bottleneck.