Many organizations struggle with the quality of their business processes. Especially in relation to the IT-systems that are supposed to support those business processes. Often the IT-systems don’t exactly do what they were supposed to do. Or the response is too slow. Or the costs have exceeded the budget. Or the project has run out of time. Or all of those.
When an IT-project has delays, this often is noticed during the testing phase. Thus people complain that testing takes too long and is too expensive. But actually the testing itself does not cause these problems, testing just uncovers defects. The fixing and retesting and other rework is the real problem!
In the book “the PointZERO vision” we have described how we address this challenge. It starts with an overall view across the whole application lifecycle. Including all activities from the early lifecycle (e.g. creating a business case) to the end of the lifecycle (i.e. implementation and maintenance). All around the application lifecycle we want to optimize the activities in the application lifecycle process. With the ultimate goal to have no need for testing, because the quality of the product meets the stated requirements and implied needs.
Three key principles
- Fit for purpose: The right quality, not too little and not too much; suitable for the intended purpose in the business process
- Right first time: Faults should be prevented; Frontload the process with quality measures
- No faults forward: Since people are fallible there will be defects; Make sure no defect progresses to the next activity in the lifecycle but remove them during the activity where they occur
Always keep in mind that quality can’t be “tested in” afterwards!
Parallel and step-by-step improvement
We work towards applying these principles by parallel and step-by-step improvement. That is to say that we won’t strive for changing all activities in one go. A Root Cause Analysis of production incidents and test defects will show where the bottle-necks in the application lifecycle are. And also we observe the IT process as a whole and determine where problems exist (for example related to IT-infrastructure). Based on this information we determine where the defects and problems are caused and what can we improve to prevent defects from occurring in the future. We carefully look at which improvements will bring benefit while the risks remain acceptable. Improving is always a trade-off between the risks of not changing the process (so what problem currently exists) and the risks of changing the process (what new problems might the change introduce).
One of the tools we use is the improvement backlog. This is a list of the identified possible improvements, and for each improvement we establish the risks which leads to the priority of each improvement. Also we estimate whether it’s a quick win, a medium term change or an improvement that brings benefit on a long term.
Three improvements in parallel: Quick win, medium term and long term
From the improvement backlog we select only 3 improvements and work on these in parallel. Why only 3? Well, you can only keep an eye on a small number of changes. So to be as effective as possible, we select a quick win, because that will show fast progress (although the effect may be limited) and thus will give a good feeling of achievement. At the same time we start a medium term change that provides a useful improvement with a high outcome. And in parallel we also start a long term improvement. Psychology makes that people often postpone starting a long term improvement because they feel it takes too long before they will get the benefits. But if you don’t start, you’ll never get the benefits! As soon as an improvement is finished, which of course is determined by measuring the effect, the next improvement from the improvement backlog is selected. So the quick wins will follow on each other quickly. This way we create a steady flow of improvements that will give the people involved the confidence that step-by-step the application lifecycle activities become more effective and more efficient.
A mountain can’t be moved in one day
While prioritizing the improvements an important consideration is the maturity of the different parts of the IT-process. Since it is not possible to change everything in one go, the parallel and step-by-step improvements first have to focus on “filling the gaps” and when the entire process gets to an equal level we can together move upwards.
Increase your business success
The ultimate goal of the improvements is increasing the business success of the organization and reducing the fixing and rework. That is achieved by applying the three key principles and using the parallel and step-by-step approach to improvement to the activities across the application lifecycle.
The right first time principle makes sure no time and money are wasted on fixing defects and rework.
Rik Marselis. Management Consultant Quality & Testing at Sogeti in the Netherlands.