Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Agile Crash Course: Agile Project Management & Delivery - Master the most important concepts & tools of Agile

Your Company Name Here - Reach 30'000 visitors/month and 35'000 software development professionals for $145.

Click here to view the complete list of archived articles

This article was originally published in the Fall 2004 issue of Methods & Tools

Don't Write Another Process

John Davenport, Q-Labs,

This article imagines a future in which organisations achieve high performance without writing any more processes. Instead, they use processes that already exist, they measure key attributes, analyse them regularly and improve them in a systematic way.

To fully cover the ground beneath this vision we need to consider 3 things:

  • what motivation is there both for and against re-use;
  • we need to look at what aspects of culture help or hinder re-using processes;
  • and it will help of we look at some examples and benefits of process re-use, so as to fully illustrate what we are talking about.

We can start by noting that all the processes you are ever likely to need exist somewhere already. They could be within your own organisation, or they could be external. It really doesn't matter. There is no need to re-invent them. So don't.

1. The Motivation for Re-Use

There are 3 principle reasons why re-writing a process is a BAD idea:

  • It focuses the conversation too quickly on process detail, and thus distracts you from business benefit;
  • It delays or even stops you from getting into institutionalisation;
  • It prevents or distracts you from measurement and hence progressing beyond level 3.

Let's look at these in more detail...

1.1 A True Business Focus

The starting point is that all process activities MUST lead to improvement of business performance. It doesn't matterhow good your processes are if your company is failing around you.

Engineers LIKE to invent things. Their whole background, genetic make-up, education and orientation SCREAMS at them to re-write the process. So what will stop them? The tendency to rush into defining a process is NOT stopped just because you already have one.

The strategic link is critical. If we wish to achieve business benefit, then we must talk about it. We must focus on:

  • Business goals/targets for processes - aligned to the organisation's strategic direction;
  • Efficient use of people's time;
  • Tracking business value.

1.1.1 Business Targets for Processes

What can help is to re-focus the whole effort on business benefit. If we start with the axiom that all process activities MUST lead to an improvement in business performance, then we are drawn into thinking about what this means in our situation, rather than the detail of the process. But this is very hard to do - especially for the so-called 'process professionals'. After all, their professional life is based on defining processes, not setting business targets for them. Clearly what is needed is a partnership between business managers and process managers. This is the first, but by no means the last, time we shall see this. If we can achieve a meaningful relationship between these two areas of the organisation, then SPI (Software Process Improvement) becomes SPI (Strategic Process Improvement).

I know of one organisation where a CMMI level 3 set of organisationally acceptable processes is available for implementation by any organisational unit that wants to do it. All that level x by time y nonsense is just by-passed. Such an approach invites you to define the REAL business benefit, and GET ON WITH ACHIEVING IT.

We can focus more clearly on business benefit by looking at some examples:

  • Deliver 500FP projects in less than 12 months;
  • Euros 1,000 per FP or less;
  • 1 defect per 100,000 lines of code, or less.

Most organisations would struggle to get the data to show where they are today against these targets. Implicit in these targets is an organisation where top management thinks in these terms and process management forms the link between such business-level targets and the engineering detail necessary to deliver them. In such organisations, process thinking stretches across all levels of the management hierarchy. If I can use the word here, the maturity of the management is well developed.

1.1.2 Efficient Use of People's Time

A second reason not to re-write processes is to make the best use of people's time. Without doubt time is the most critical resource for most organisations today. To waste it is nothing short of criminal. Yet time and again organisations re-write existing processes - often for no known business benefit. Sometimes the given reason is to improve a process that isn't even fully implemented yet. What a waste!

Quite simply, an unimplemented process is not worth writing.

If time is the most critical resource, it is also true for most organisations that the amount of SPI resource is limited. In such a scenario, every person-day re-writing a process we already have is one less person-day analysing process data or implementing process improvements. We could be

  • Designing a new product;
  • Enhancing an existing one;
  • Analysing an existing process;
  • Taking the organisation to higher levels of process performance.

You often hear the phrase "don't re-invent the wheel". It's often used cynically by people who wish to prevent some activity taking place. It's interesting to look at the development of the wheel. The earliest known wheels, constructed in ancient Mesopotamia, date from about 3500 to 3000 BC. Radial spokes were devised around 2000 BC. Pneumatic tyres were added in 1888, and light-alloy wheels were developed c1950. Five and a half centuries of development and in all that time, no-one ever re-invented the solid stone wheel! By contrast, some organisations have several - even many - versions of a process co-existing (e.g. project planning); all have been individually defined; all have been individually paid-for; none are in wide-spread use, and there is no comparative data available. Such organisations, clearly, can afford to waste their software engineering resources in meaningless (non-business value-adding) activities. Maybe it is part of some punishment regime?

1.1.3 Tracking Business Value

Finally, in our section on business benefit let's look at how people recognise it. The key approach has to be Return On Investment (ROI) - the cost of process improvements is compared to the value of recognised improvements. Some people limit improvement to the measurable aspects of performance, e.g. productivity, time to market, and defects. Others will include factors such as:

  • the business opportunities that can be addressed once projects move out of the tar pit;
  • the lower lifetime costs of improved products;
  • the greater market share and revenue that new and improved products can bring.

However we focus on business benefit, the crucial thing is that we MEASURE it. Measurement is critical to improvement for two reasons. The first is without measurement all you have is constant change, with no idea of whether it is for the better or the worse (although there will be a lot of opinions):

"Without the right information, you're just another person with an opinion" - Tracy O' Rourke, CEO of Allen-Bradley.

The second reason is that when we start to measure things we start to ask questions - detailed questions - about what we are measuring and how to measure it. These questions can seem annoying and trivial when we are trying to implement some large, strategic vision, but they are actually key to that implementation. Without a detailed idea of what we are measuring and how, we will never manage to gather the data we need to quantitatively demonstrate our improvement. In the extreme this can prevent the implementation of a process. More usual (and more depressing) is that at some stage the organisation realises that it cannot measure the process without additional effort, and decides to forgo that effort. Thus a process is (sort of) implemented, but no data on its use or usefulness to the business can ever be gathered.

1.2 Institutionalisation

Institutionalisation entails building an infrastructure and a corporate culture that supports the methods, practices and procedures of the business so that they endure after those who originally defined them have gone [CMU/SEI-93-TR-24, p4].

That is to say the way of doing things becomes independent of any individual within the organisation (remember level 1 is the realm of the hero). The real issues in PERFORMANCE IMPROVEMENT are in implementation (such a nicer word for institutionalisation :-). Again, this gives us a good reason NOT to re-write a process. Why waste time re-defining any processes? Get right into the real stuff!!

Many organisations spend as much time or more in definition than in institutionalisation. For some reason they don't like to go there. Maybe the word itself is a barrier. As Groucho Marx says, "who wants to live in an institution?". It's not a nice word. Yet the culture of the organisation - the institution - does affect behaviour. Despite the fact that we don't like looking at it, there is a critical issue here.

Institutionalisation involves building a culture that supports the way the business wants to do things. But in the same way as "practice makes perfect" only if the practice itself is good, so the culture will only support continuous improvement if it is a culture of continuous improvement. Too many times in organisations we see a culture that venerates the ancients (past and present management) rather than (or indeed instead of) being results-focused. In such environments re-writing processes is usually seen as OK. Definition is viewed more positively than measurement. This failure or refusal to be results-focused gives the implicit go-ahead to continuous re-design of processes, committing organisations to live forever in a perpetual repetition of levels 1 to 3. Let's look at why.

However you define the process improvement cycle, it will look something like this. Some organisations spend so much of their time on process definition, that all other stages get performed badly, if at all.

In implementing a new process, we face the challenge of changing an existing habit. This is very difficult to do.

Let's look at why...

Changing Habits

Habits are consistent, often unconscious patterns. They drive our behaviour.

For those who drive a manual car, think of the first time you changed gear. All those things to remember and do at the same time. Now try and remember the last time you changed gear. You can't. It is so ingrained a habit that it is no longer even conscious.

Imagine what would happen to your driving performance if the method of changing gears was changed. Even if the new method offered the prospect of being more efficient, initially you would not be as good as you were previously. Psychologists tell us that 6 times is the minimum needed to commit the new behaviour to memory.

This takes a lot of time and effort. Until they are a new habit we are not as productive as we were before. Being a U.K. driver, the first time I drove a left-hand drive car, I put the clutch in and opened the door!!

Because habits are often unconscious, to change a habit requires that we:

  • explicitly identify the activities that we wish to change;
  • develop the new set of activities we wish to put in place;
  • train people in the new activities, including any new tools or techniques needed:
  • practice them some 6 or more times until the new activities become stronger in our memories than the old ones;
  • practice them some more, until the new activities become habitual (and efficient).

This takes a lot of time (more than effort). Many improvement projects remove the monitoring effort before the new activities are established and the old habits simply re-assert themselves. And usually management has made no allowance for the obvious lower productivity during the change-over. Because of the length of time needed here, it is key to get into institutionalisation as quickly as possible. An active approach to re-use means that institutionalisation is the first step of the process improvement cycle.

1.3 Measurement

The third good reason to promote re-use is to ensure a good approach to measurement. We've already mentioned the importance of measurement:

"Our managers have all gone through the frustration of debating how high are 'high' costs, how poor is 'poor' quality. They know that once we set up units of measure, the debate shifts from the meaning of adjectives to doing the job at hand, which is as it should be."
Managerial Breakthrough, J. M. Juran, McGraw Hill, 1964

If chaos is the enemy, measurement is the foundation that will keep chaos away. In the Foundation stories by Isaac Asimov a process group (Harry Seldon) designed a system to reduce a period of 30,000 years of chaos to a single millennium by founding 2 sites; the first one to ensure the development of a technology superior to that of the forces of chaos and the other to monitor progress against the improvement plan. To carry this simile into measurement, the first foundation is an organisation's ability to define, take and analyse key process attributes. The second foundation is the small group of trained people who monitor the evolution of the improvement plan, making small but crucial adjustments where necessary. If Asimov had the vocabulary available to him, I'm sure he would have called the Seldon Group the SEPG (conversely, why didn't the SEI call the SEPG the Seldon Group?!).

Although we measure things at levels 1 and 2, it is at level 3 that it transforms from a PROJECT tool into an ORGANISATIONAL tool. Only when we have an OSSP do the measurements we take begin to give us information about how the PROCESS is performing. And only then can we begin to decide how to update the process (as opposed to re-write it), to deliver stated business benefits. Level 3 is the fulcrum between (essentially) unmeasured, qualitative processes and quantitatively controlled processes. I'd like to use some slides from a presentation by Dr. Sontakke from ICIL which illustrate the pivotal nature of level 3.

Preparing for Measurement

Level 1 is simply where we all start - the primordial soup out of which process organisms develop. At level 2 individual projects have adequate controls, but they are individual to each project.

Level 3 is created when we intelligently take our level 2 process assets and forge a standard s/w process (OSSP) for the whole organisation.

But level 3 isn't an achievement - it's a PREPARATION. A preparation for the real process work of measuring, monitoring and improving.

In The Measurement Landscape

Once we get to level 3 we are in a whole new universe. We can now accumulate and compare data from all our projects. Only now is it comparable. We can identify areas where we wish to improve performance, and we can design and implement those improvements.

In doing this we are improving the process - not re-writing it. For the first time ever, we are not re-writing the process. This is the true start of process maturity. Level 2 is process adolescence.

You might say that the mark of a true level 3 organisation is that it has stopped writing processes. Level 3 really is pivotal.

2. A Re-Use Culture

Section 1 was intended to establish the motivation for reuse which, put simply, says that until you have stable established processes that you are monitoring and improving quantitatively, you really have no idea whether one process definition is better than another and you have more chance of improving your company's fortunes by betting on the lottery.

In this section, we want to look at what aspects of culture support process re-use, and thus moves us to higher levels of process maturity. There are many definitions of culture, but all share some or all of the following elements:

  • cognitive frameworks, shared meanings and perceptions;
  • beliefs, attitudes, and behavioural codes;
  • values, stories, heroes & heroines, symbols and rituals.

All are intended to align the many activities of the organisation, which is the key to organisational efficiency.

"Organisational culture is the key to organisational excellence."
Edgar Schein, Professor of Management, Massachusetts Institute of Technology.

This quote rightly points to the importance of culture to organisational excellence, and a consideration of the concept of alignment (see Peter Senge, The Fifth Discipline, pp 234 - 235) shows us why.

Culture: The Magnetic Model

In order to achieve EFFECTIVE, LASTING change, all we need to do is change the behaviour of everyone in the organisation J. When everyone in the organisation is pulling in the same direction, this is achievable.

However, the difficulties that organisations have experienced in developing effective process improvement leadership illustrate the difficulty of this apparently simple approach. Why is it so difficult to align people in an organisation?

Most change programmes just try and change things. The better ones at least go to the trouble of explaining what the change is, or at least the need for it. But even this is not enough. The approach is based on a logical approach - "If I explain it to you, then you'll do it, won't you?" But people are more than just logic engines. In the left brain-right brain model the left brain does indeed deal with logical, rational, analytical tasks. In addition however, we humans gloriously have a right brain which is dedicated to imaginative, creative, emotional tasks.

Just telling people what we want to achieve is necessary, but not sufficient to achieving our aims. Any organisation hoping to create permanent improvement needs to engage both brain halves. To pick up one of those culture definitions, we need to ensure that actions and beliefs are coherent.

Without process improvement leadership people are working just as hard, but often as not against each other. The overall effect is minimal. We need the alignment that appealing to right-brain concerns gives us. The overall effect is much, much stronger.

Culture: The Integrity Model

No set of new activities, however much it is wanted, will prove effective if it runs contrary to the values and beliefs of the organisation. There needs to be compatibility between the activities and the attitudes of an organisation. For example, do we set an objective to analyse process data every year, but have an attitude in the organisation that says sales visits are more important?

The integrity model, first introduced in 1984 by John Seddon of Vanguard Consulting shows how we can integrate both brain halves in the pursuit of better results.

In the integrity model the left-hand path deals with left-brain considerations. Given a vision, it develops logically the strategic goals, objectives and activities needed to turn the vision into a set of business results. The right-hand path deals with the right-brain considerations of the workplace values, attitudes and behaviours. We can use this model to investigate the elements of a culture which is supportive to re-use. And it's bigger than you might have thought ...

Vision - Must include something on 'measurable' or 'demonstrable' superiority. We need to be careful and explain clearly what we want to be best at - maybe people are trying to be the best at writing processes!

Values - I know organisations where s/w people say "Oh, we don't have project managers because we only deal with people costs here"! And management let them!! This denigration of the importance of people also promotes the re-writing of processes - after all, it's only people's time that is being spent! Organisations with these values deserve the resultant behaviours - constant re-defining of processes and a total lack of measurement and performance information.

Values - Trust can only be obtained if you are involved with people. Attention to output is insufficient; attention to detail / process / the how must also be there. Trust only comes with integrity. The only way, for example, to make the message "work smarter with fewer resources" work is to do it first at the organisational level. In the end it boils down to whether we trust our own people or not (Theory X / Theory Y). Many organisations do not.

Strategic Goals - The broad achievements the organisation wishes to achieve. These must flesh out the vision, & be compatible with the values. Often organisations don't share their strategic goals. You can't expect people to work towards something they are ignorant of. Furthermore, because the strategic goals are hidden, the vision doesn't make sense because you hide from people the added detail that helps them instantiate the vision in their particular circumstances.

Attitudes are the things that direct our activities when we ask the question, "what shall we do now?" Many s/w groups focus quite naturally on technological issues. But these are only necessary, not sufficient to guarantee success. The attitudes below are ones I have found to help correct this imbalance - giving some airtime to people and process issues:

  • Customer first;
  • Intelligence before standards;
  • Invite constructive review.

The Objectives for each specific improvement programme will be the specific targets that need to be met to achieve the strategic goals.

It is in the day-to-day behaviours where all the planning and preparation comes out. Projects run better when people keep an holistic view of the entire project and are prepared to own any problems that they discover. This entails being responsible for resolution of the problem, not necessarily solving it.

In addition to the activities needed to build the product, we need activities which keep the focus on process re-use and performance.

Finally the organisational support must do just that - support. For example, if we have a vision to re-use processes, then we need systems and documentation that help that to happen. For example:

  • There should be a common notation, basically an IPO (input - process - output) notation like IDEF or ETVX;
  • There shouldn't be too much detail in the process description or it doesn't travel;
  • There needs to be a process architecture defined for the whole organisation;
  • The process architecture must allow local organisations to add their own procedural detail to the processes.

It's a fairly large model when you go through it like this.

In fact all the elements of it already exist, either explicitly or implicitly in every organisation. The novelty here is to make it all explicit, pull it all together and ensure it is all coherent. This coherency gives us - and supports - the new process behaviours. This coherency gives us INTEGRITY; integrity in our aims, in our attitudes and in our behaviours.

Such a culture leads to consistent, repeatable, top decile performance.

Cultural Enablers for Process Re-Use

We can draw all the discussion on culture together with the table below:

Management commitment

easier if there are explicit links between business objectives and PI activities, must emphasise

Engineering attitude

engineers must be open to the idea of using processes actively so as to meet both customer and organisationaltargets for product content, and engineering productivity.

Process Notation

There needs to be a common notation so that different people in different parts of the organisation can easily recognise and absorb any new or updated processes.

Level of Detail

you have to start somewhere; why always choose a blank piece of paper? More important - not too much detail or it cannot be ported.

Approach to Processes

NIH (Not Invented Here) - this is the inverse of what this normally means. We need a state of heart & mind that explicitly looks NOT to design a process; a pride in the amount of process used but not invented.


If no-one knows what processes are available, then they will continually re-invent them. Of course, the SEPG forms a natural focus for communication and re-use.

3. Examples & Benefits

To draw this discussion to a close, lets look at some examples where organisations choose explicitly to re-use process assets and tease out what benefits lie therein.

Examples of Re-Use

  • 10 minutes to define an estimating process (by re-using one from a sister organisation);
  • 3 months to produce an entire software development system, certified to CMM level 2 (a 75% reduction on the last time a unit within the same company had done it);
  • 10 months to move from CMM level 1 to level 3, compared to a median value of 19 months to move from level 2 to 3 (SEI, Maturity Profile, March 04);
  • 56% effort reduction in establishing a CMM level 2 system.

Benefits of Re-Use

Mirroring the three areas we have looked at in our discussion on re-use, we can identify 3 major benefits resulting from an active policy of re-use:

  • A more business-oriented focus to SPI activities;
    the simple fact of re-use focuses people more easily on what it is they want to achieve rather than how.
  • A sharper focus on measurement; and
    measurement now becomes a valued companion in the business mission - not an annoying imposition or uninvited guest.
  • The increased commitment of senior management to SPI.
    when management can see that they are getting something they can recognise and value (progress against their business goals), their commitment increases.

So, to summarise:

  • All the processes you will ever need already exist. If you don't have one that you need, email me and I'll give it to you.
  • The key issues in process improvement are in implementation. So let's not waste any time defining processes that have already been defined. Let's get into the tough stuff as soon as we can (to start reaping the benefits as soon as we can).
  • Typically only a few organisations (17%, SEI, Maturity Profile, March 04) ever reach the stage where process improvement is driven by quantitative performance data. How much is this because organisations keep re-writing processes, and so never settle down to measure them?
  • Focusing on the collection and aggressive use of appropriate process data holds far more benefit for an organisation than defining (again!) their processes.

In short, stop defining processes - measure and improve the ones you've already got!

Related Software Process Articles in Methods & Tools

Back to the archive list

Methods & Tools
is supported by

Simpliv IT Courses

Software Testing

The Scrum Expert