How do I encourage root cause analysis rather than focusing on short - term solutions?

Question

As an IT auditor at my workplace, focusing on short-term solutions seems to be the preferred way rather than doing a root cause analysis (RCA) and letting the results guide further action.

For example, change management has been consistently weak from past audit results. When a change request has insufficient evidence of following the company Software development life cycle (SDLC), I most often get retroactive approvals on the spot.

The SDLC process is not burdensome and seems reasonable. Standard phases of progress such as Requirements definition > Development > QA > User Testing > Production release is defined and documented with upper management support. There are separate, but interactive, teams on each phase of the SDLC such as development, QA...etc. Tools for tasks such as source code version control / release control and code reviews are in place and being actively used.

Such carefree response in the example casts doubt on the effectiveness of the SDLC process. Focusing on short term, band-aid fixes is convenient but does not solve historical trend of control weakness. It is also an missed opportunity for process maturity.

Responding to some of the answers here that this impractical or misguided, I like to see our role as more of an advisor rather than enforcer. Basically, what can we do better than where we are now? Rather than asking, who is to blame, let's find out where the process is deficient so we improve the next time.

How can our team influence changing to a more long - term view focused on improvement and root cause guided action?

Answer 1

I think the problem is that the processes as defined in the company standards, like the SDLC, were never actually implemented on the work floor, not for a single day. They are fiction.

I think that too often it goes something like this:

• The company does software development, using some ad-hoc process that evolved over time, invented by people trying to get work done.

• The company decides it needs to get certified to some ISO standard, for instance because some potential customers require that

• External ISO standard experts are brought in

• SOPs are drafted that follow the process as the standard requires it, but that do not reflect the current way of doing things (as the company didn't get where it was with the standard in mind)

• Everybody knows the actual process followed is not what's in the SOPs, what's in there is just there to adhere with the standard, so everybody is cynical from the get go

• The company gets ISO certified based on the SOPs

• Internal quality officers are distraught that the SOPs aren't followed!

Note that at no point was improving actual quality was a concern.

It would make more sense to start with a software development procedure that is drafted by the software developers and just describes the process that is actually followed. This will be far removed from what the ISO standard requires, may be completely different per project, but the people will feel that it is connected with reality.

Then improve quality slowly, step by step, based on root cause analysis of actual problems, input from the developers (who usually have a pretty good idea of how quality of their process can be improved), and cost/benefit analysis -- the company needs to make a profit after all. Maybe the best way is not to prevent errors but improving the company's capability of fixing them very quickly when they happen. There will also be a push towards the ISO process because of marketing reasons, and there may be some good quality ideas in there too, but it should be part of the improvement process to work in that direction.

Unfortunately, some businesses decide that getting certified is just too important for them, and they end up with fiction and cynicism, and people not doing what the procedures say in order to get work done.

Answer 2

How can our team influence changing to a more long - term view focused on improvement and root cause guided action?

In my personal experience, audit goals have nothing to do with root causes.

They just look for violations of policy and standards, then report to management. "Passing the audit" any way possible is the sole goal of the teams being audited.

This isn't a surprise. If you put a lot of emphasis on "adhering to standards" then the teams that want to get real work done often find it more efficient to put minimal effort into adherence, due to pressures to get things into production more quickly. The standards are considered a burden, overhead to be avoided as much as possible. And to some extent Agile is encouraging teams to move away from such strict SDLCs and more toward lighter, more streamlined methodological processes that meet the more immediate needs.

Consider that you may be in the wrong department if you want to make real change happen. For change to happen it must be a commitment from the top. And most likely that commitment won't target the Audit team as the change agent.

Answer 3

You're pushing against inertia and apathy. The best way to accomplish this is at the top, not in general. Changes like this need enforcement, not encouragement to be really effective.

Unfortunately (or fortunately) auditors usually don't get this sort of authority on their own.

Answer 4

There are two separate things here that seem confused. One is "root cause analysis" - figuring out what was the root cause of a problem, and try to fix the root cause. The other is following a process to handle changes in the product.

In my experience, "root cause analysis" is very rarely used. "Root cause" could be "inexperienced developer who didn't get the necessary guidance", "overconfident experienced developer who became careless", "not enough testing" - all these don't produce changes in the product, but in your development process. And since you should have taken action, this shouldn't happen again and again.

If the process wasn't followed and a change moves into production with insufficient planning, testing etc., well, there isn't that much you can do about it. After a car crash, no point telling the drivers to drive more carefully. What you would have to do is influence at the time when it is happening.

It is quite possible with the right software to enforce that for any change some form must be filled out (hopefully with well thought out requirements), that the work done by a developer is marked as "reviewed by someone else (hopefully after reviewing it), and that it needs to be marked as "tested" by yet another person (hopefully after testing it), before it can move into production.