Jasper just sent out his prioritization list to Peter. As he wants to know if he’s correct and to give Peter some help in seeing the whole picture again. While on his lunch break Jasper sees the news on problems at the railway.

As he pressed the send button Jasper was relieved that he’d given Peter some help with understanding the bigger picture and issues at his organization. And as it was time for his lunch break he looked at the news on the Internet.

‘Backup of switch software caused train chaos’
“What’s this?” Jasper asked himself.
He read the article and it said that a problem in the backup software of the switches didn’t function correctly and resulted in chaos on the railway.

Now a few days later Jasper is still amazed on how big the effect of good software can be on everyday life.

“Why do project managers only think about time and money?” he thought to himself.
“Doesn’t this also cost a lot of money? It did cost a lot of time for everybody that wanted to go by train. And I don’t expect the project around this software to be finished within budget and time. Maybe we do something wrong.”

And as he consulted to himself even more he was thinking about his own assignment. That also had poor quality, why else do they have more then ten thousand defects to look at. But luckily he was doing something about it. And he was going to do something about it. Instead of being reactive, he was going to be proactive. Take on the issues in quality before they would be a problem! And maybe even save time and money in the process!

Jasper talked with Peter about the priorities and has now a prioritized list of projects he can start on with a root cause analysis.

Jasper was looking at the list he just made.

The first project he had to go through had more than 4.000 defects. “That’s going to be a hell of a job.” He thought.

But first he had to go a little bit deeper into the theory behind root cause analyses.

He started looking online for information and started to write what he found.

The Root Cause Analysis is a structured approach to identify the factors that resulted in the nature, the magnitude, the location, and the timing of the harmful outcomes (consequences) of one or more past events in order to identify what behaviors, actions, inactions, or conditions need to be changed to prevent recurrence of similar harmful outcomes and to identify the lessons to be learned to promote the achievement of better consequences. ‘Success’ is defined as the near-certain prevention of recurrence.

The root cause information concerning analyzed defects is used to:

• identify the best moments for improvement in the SDLC to prevent defects in the future, and
• improve the monitoring of (test) projects.

This will result in a better quality of the complete SDLC and the system under test and in a reduction of the number of detected defects in the test levels.

The practice of RCA is predicated on the belief that problems are best solved by attempting to address, correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is more probable that problem recurrence will be prevented. RCA is often considered to be an iterative process, and is frequently viewed as a tool of continuous improvement.

RCA is typically used as a reactive method of identifying event(s) causes, revealing problems and solving them. Analysis is done after an event has occurred. Insights in RCA may make it useful as a pro-active method. In that event, RCA can be used to forecast or predict probable events even before they occur.

Jasper reminded himself he had a lot to do before he had evaluated all 4.088 defects and that he had to start as soon as possible. But first he sent out his table in an email to Peter. Asking him is some things needed a change, but also to see the whole picture. As Jasper thought that Peter had lost that among the way.

Source: http://en.wikipedia.org/wiki/Root_cause_analysis

Jasper has just started at a new client and is trying to find out how he can move forward with more that 18.000 defects to get through.

It was almost 6:45 and he was waiting a few more minutes to call Peter. Yesterday Jasper learned about root cause analysis and he wanted to put it into practice, but he needed to start somewhere. It still were 5 projects and 18.356 defects. Peter decided to call a few minutes to late, to look not too eager.

He pressed the dial and the phone rang.

“Peter!” the other end of the line sounded.
“Hi Peter, this is Jasper. Margreet it was a good idea to call you at this moment as you had some time to spare. Is that OK with you?”
“Yeah! How can I help you Jasper?”
Jasper could hear Peter in car and he had a lot of background noise, but still he could hear what he said. “Well, I’ve found a way to go through all the defects and find out where there were any issues that could have been done earlier. It’s called a root cause analysis. I’ll explain that if you want to?”
“Please do, but maybe not now. Please go on.” Peter replied.
“OK, well to do this root cause analysis I need to go through all the projects that you’ve named. But as that is a lot of work I wanted to know where you want me to start. In other words, which project or projects are the most important to or are the most representative to begin with?”
As Peter started to answer to that question he felt that he had to know the answer to this, but couldn’t give it directly. So he started to give an answer that bought him some time. “Can you name that projects again? I’ve had so many projects come along and I cannot give you the answer without knowing the name of the projects you’re talking about.”
“Sure, of course.” Jasper replied. “They are Product Output, Waste 5, Route & Planning, Output Reporting and Serious Delivery.”
“Shit!” Peter thought. “I know one and I’ve heard that Output Reporting went terribly wrong because of Product Output. But that’s 3 out of 5. What were the other two?”
Jasper mentioned that Peter didn’t reply directly and was wondering why.

After a few seconds Peter replied. “Well it’s not that easy to answer. All the projects were representative of our work here, but to say what was the biggest risk or what was the most representative…”
“I know it’s not as easy as I ask it, but is there something you can help me with?”
“Not on the top of my head.”
“OK. Let’s try this. What was the project that stayed the most with you?” Jasper asked.
“That was Waste 5!” the fast answer was. Waste 5 was wrong from the start. The project manager that was doing that project even got sent back to the company that provided him as being incompetent. As a result everything kept going wrong and they had blamed the project manager the whole time.
“Perfect! And now name another one, the one after that.”
“They were all equally important!” Peter said.
“That’s what they all say.” Jasper thought. “That can look so, but that cannot be true. But maybe this can help. This Waste 5 is the most important one. OK. But if you should give a grade to the other four; a grade of 9, 5, 3 and 0. What would go where?” This method helped in prioritizing product risks, so maybe it could help here.
“So you want me to give them a grade?”
“Yes!” Jasper said.
“OK then.” And there was some time for Peter to answer. “If you grade them with 9, 5, 3 and 0 I would say that Product Output is a 9, Outlook Reporting a 5, no 3, Route & Planning a 0, and Serious Delivery a 5.”
“Thank you. I’ll write this down and sent you an email about it. Please have a look at that later today or tomorrow and reply to me of something changed. I’m going to start on Waste 5.”

After finishing the mail to Peter he went on to work on the root cause analysis of Waste 5.

Still driving in the car Peter was thinking about what Jasper mentioned and that he couldn’t give out the answer directly. He wasn’t too pleased that Jasper had asked him this question and pushed for him to make a choice.