veryard projects - innovation for demanding change

SPICE

Software Process Improvement Continues Eternally

on this page

> principles of quality improvement
> barriers
> our approach
> examples
> next action

on other pages

veryard projects
home page

software quality management

people issues

how to recognize a good software process

	A good software process is constructed from good components.
	A good software process is well-connected.
	A good software process is well-managed.

yes, but how do we recognize a good software process?

	Knowing what to look for - and being aware of what's missing. Knowing the right questions to ask - and using experience to interpret the answers.
	Having the flexibility to sidestep the small issues, and go for the big stuff.

... and why do we care?

	Improvements to the software product. Greater reliability of producing high quality software products.
	Higher productivity & cost-effectiveness in software projects. Reduced wastage from rework.
	Higher morale and job satisfaction for software personnel.

For many of us, software process improvement is so obviously a Good Thing, that the first question perhaps ought to be: why isn't it already happening?

But the fact remains: software process improvement is - perhaps surprisingly - hard work to achieve. Many organizations need help to make it happen: to start it happening and to keep it happening.

Principles of Software Process Interventions

veryard projects > software process improvement > principles

	We distinguish the process-in-use from the process-on-file. All software projects, programmes and organizations have at least one software process-in-use. (Some have lots of rival processes in parallel use.) Many software projects, programmes and organizations also have a software process-on-file (in other words, the officially documented process). This may include official variants or plug-ins for different circumstances. Sometimes there is a degree of correspondence between the process-in-use and the process-on-file. (Unbelievable isn't it?) But the process-in-use usually starts further back, and goes on longer.
	A good software process is constructed from good components. (This isn't rocket science. The components are well-known. See SEI CMM or SPICE for a checklist.)
	A good software process is well-connected. internally cohesive - the components properly wired together connected with the organization's policies, roles and capabilities connected with the technical platforms and facilities connected with the business purpose and ethos
	A good software process is well-managed. risk/reward focus measured self-correcting and improving
	Some form of metrication is required to get higher levels of process improvement. All the process assessment models also demand it. For example, metrication is a crucial requirement for attaining Level 4 of the SEI Capability Maturity Model, and ISO 9000 and its derivatives also require some degree of metrication. Lots of organizations devote considerable effort to collecting the wrong metrics - the challenge is to define and use the right metrics. What are the advantages of using this or that model? How can process models be used without introducing additional levels of bureaucracy? How can staff (especially those on short-term contracts or third parties) be motivated to contribute to process improvement? How can a culture of process ossification be replaced by a culture of continual process improvement? How to select a small set of powerful yet simple metrics?

ISO Principles of Quality Improvement

The quality of an organization's products, services and other outputs is determined by the satisfaction of the customers who use them, and results from the effectiveness and efficiency of the processes that create and support them.
Quality improvement is achieved by improving processes. Every activity or item of work in an organization comprises one or more processes.
Quality improvement is a continuous activity, aiming for ever higher process effectiveness and efficiency.
Improvement efforts should be directed towards constantly seeking opportunities for improvement, rather than waiting for a problem to reveal opportunities.
Correcting an output from a process will reduce or eliminate a problem that has occurred. However, preventive and corrective actions to eliminate or reduce the causes of a problem will eliminate or reduce any future occurrence. Thus, preventive and corrective actions improve the processes of an organization and are critical to quality improvement.

[Source: ISO 9004-4]

Barriers to Software Process Improvement

veryard projects > software process improvement > barriers

Attention must be given to issues of organizational change, and the barriers to process improvement. Some kinds of process improvement are easier to get than others.

	Software developers who are so complacent (or brain-dead) that they think they have nothing more to learn about doing software well.
	Managers who have so little confidence in the intelligence and creativity of their staff that they are not willing to EVER let them do anything new, in case a fragile process falls apart completely.
	In many organizations, there is an improvement ceiling: you cannot even think of going any higher/better than this. External consultancy is usually required to recognize the existence of this ceiling, and to help raise the ceiling.
	Interpersonal conflicts can also get in the way of process improvement. We were working with an organization that employed a high proportion of contractors on a millennium compliance (Year 2000) programme. These contractors had been informed when they joined the project that they were expected to work as if on a production line. But it was clear that any ideas for making the process more effective or efficient would be discouraged. The main source of this discouragement was those staff who had been working there the longest (typically in project leading / supervising positions), who may have felt most threatened by this influx of contractors with their potentially disruptive ideas.

Our Approach

What we're looking for

Step		Comments
1	We check for components of the software process that are missing or weak.	We use CMM and SPICE as checklist. Quite often we find major holes in the software process - with some of the CMM Level 2 grossly neglected. At the other extreme, some of our clients are already at Level 5, and are looking for further refinement and innovation.
2	We check for connections that are missing or weak.	Things sometimes get lost in the no-mans-land between projects or departments. We often find major disconnects between separate parts of a process, programme or organization.
3	We check for mismatched expectations.	When a project manager tells us that X is someone else’s responsibility, we like to double-check. We’ve found (and resolved) lots of issues that way. Proper use of a programme method such as Prince will capture some of these issues - but not all of them.
4	We check for risks that are uncontained – in other words, not properly owned, understood or bounded.	Obviously any holes or disconnects in the process represent potential risks. And there may also be external (business) risks that are known about but not properly dealt with.

When we conduct a brief assessment, our approach is illustrative rather than comprehensive. Obviously we cannot expect to check everything thoroughly in a few days. However, we are usually able to get a fairly realistic sense of the amount of work to be done, as well as identifying the major issues and some quick wins.

Managing the assessment

Obviously we have to follow a managed process ourselves - and here it is.

Context Identification	What are the objectives and strategies? Who are the stakeholders? What are the stakeholders' expectations?
Model Selection	Which software process model (if any) are we going to use as a benchmark?	The software specific models include: SEI Capability Maturity Model, ISO-SPICE, Bootstrap, Trillium, ISO 9000-3, TickIT. General process models applicable to software include: ISO 9001, Baldrige, EFQM. If the organization is familiar with one of these, or can get comparison data from other organizations (especially direct competitors), then this may be the one to choose. Of course, in some cases, the software organization may be faced with a demand to use a specific model by senior management or by a major customer (such as Government).
Software Process Assessment	What is the current state of the software process, as measured against the selected benchmark?	A full and formal assessment may be demanded, but often a quick and informal assessment can be just as useful.
Identify Improvement Opportunities	What can/should be done to improve the software process?	We like to find a mix of opportunities: small and large, things that can be done immediately, as well as things that will take longer. At first, the enphasis is on finding and implementing specific improvements. Gradually the emphasis shifts to establishing a mechanism and culture that goes on finding and implementing improvements.
Set Process Improvement Target	What level of process improvement do we want to achieve, by when?	For example, it may take 12-18 months to go up one level of the SEI Capability Maturity Model, or to get certification against ISO 9001 or TickIT.
Agree Priorities and Plan	Allocate time and resources to selected improvement opportunities, as well as to general improvement mechanisms.
Monitor Improvements	Has the improvement been successfully implemented? Has it had the desired results? What is the new state of the software process, as measured against the selected benchmark?
Review Process Improvement System	Is the process improvement system working effectively and cost-efficiently?

The initial stages are best performed in a workshop with key software staff and stakeholders. The later stages are typically carried out by the management team, or by a person reporting to the management team. Consultancy support is usually required mainly in the initial stages, with mentoring and other support available throughout.

Practical Examples of Software Process Interventions

veryard projects > software process improvement > practical examples

Here are a few examples of recent work in software organizations.

Client	Complaint	Intervention
Large Utility	They had implemented a CASE tool - and were now complaining that they weren't getting the expected improvement in productivity.	But when we explored this complaint, we discovered that there were no clear targets for productivity improvement, and no plan for achieving it. In fact, everyone we spoke to thought it was someone else's responsibility.
Software House	The account managers were making unrealistic promises to customers.	With our help, the company implemented a soup-to-nuts software process that included proper checking of proposals and contracts before they went out to customers. Unusually, this software process explicitly included the marketing end as well as the programming end.
Telecoms Company	Failure to exploit the chosen CASE tool to its perceived potential.	We found several major disconnects in their process. Insufficient connections within the business units. The senior management agenda was better suited by the purchase of standard packages, whereas line management and users demanded locally unique features. The IT manager within the business unit primarily represented the senior management agenda. Insufficient connections between IT projects and the business. In particular, IT projects responded to a stream of operational and tactical requirements, but without clear direction from the IT managers within the business units. (“Job Jar”) Insufficient connections between two contrasted development strategies: “buy” and “build”. Insufficient direct connections between IT projects. In particular, an expectation that coordination between projects would be done by supplier personnel. Insufficient connections between development tools and IT environments. Lack of interfaces between different environments and platforms. Lack of any tool to bring together all systems and data, regardless of source or development platform. Furthermore, we found that the organization had never explicitly selected the CASE tool as its preferred application development environment, and had never gotten around to rolling it out in the development organization.
Software House	Project slipping. No apparent sense of urgency. Inability to focus on priorities.	We identified a lack of discipline and clarity in the organization, allowing projects to run on unchecked. We also noted poor boundary definition, e.g. between business and IT. We installed a risk management system that helped to pin precise responsibilities onto named individuals, and helped them escape from a collective fascination with commercially unimportant technicalities.

Web Links

veryard projects > software process improvement > web links

Information Services	Process Web Centre GDPA (University of Bremen)
Process Assessment Models	The software specific models include: Software Engineering Institute Capability Maturity Model, ISO-SPICE, Bootstrap, Trillium, ISO 9000-3, TickIT. General process models applicable to software include: ISO 9001, Malcolm Baldrige National Quality Award European Quality Award (EFQM).
Process Descriptions	OPEN (Donald Firesmith)
Process Tools	Process Director (Aonix - formerly Select/Princeton Softech) Process Engineer (Computer Associates)

Next Action

If you share our enthusiasm for software process improvement, please contact us to discuss further.

top

home page