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?

  • 3
    This is a bit short for an answer but what are the business costs of not following the process? If the only downside is that an auditor says that you need to fix up some documentation long after a change goes live, that's probably not something that is going to get traction very easily. If, on the other hand, sloppy change management is the root cause of some big, important system being down or some bug that cost the company a ton of money and following the process would realistically have prevented that, that's something that is much easier to get buy-in for improving the process. Nov 8, 2016 at 1:18
  • 1
    Maybe the process is too bureaucratic -- sometimes the answer to "what can we do better?" is "fix problems asap with as little process as possible". You can never prevent problems from arising, but that is OK if they can be fixed within minutes. If the process is in the way of that, fix the process. Nov 8, 2016 at 12:43
  • 1
    "Standard phases of progress" - that's your whole issue right there. Software development does not work like that Nov 8, 2016 at 14:07
  • @BradThomas - it certainly does in some companies (I'm not saying that's a good thing). Maybe that's how it works in the OP's company. Nov 8, 2016 at 14:26
  • @WorkerDrone, yes and one can also push a round peg into a square hole. The phases of the SDLC have huge natural overlap Nov 8, 2016 at 14:29

4 Answers 4


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.

  • Thought more about this and points 4 and 5 captures nicely what I think the root issue is. Theory vs practice, spirit of the law vs letter of the law...
    – Anthony
    Nov 29, 2016 at 1:37

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.

  • A very cynical view of the role of audit. We want to see ourselves as more of an advisor than a policeman
    – Anthony
    Nov 8, 2016 at 12:00
  • @Anthony in my company Audit is part of Governance. I agree with Joe that being a "change agent" isn't part of their charter. Nov 8, 2016 at 12:07

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.


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.

  • It could be chalked up to "human error". Think what OP means is actual technical root cause - ie. there was infrastructure "quirk" nobody bothered to mention or didn't even know at a time and that broke the application. Actual things that you could draw a "lesson learned" from. As always chance for common sense judgement to prevail :) Nov 8, 2016 at 13:08
  • 2
    Actually "inexperienced developer who didn't get the necessary guidance" isn't the root cause. How come he didn't get the necessary guidance? How come an inexperienced developer could cause damage? Nov 8, 2016 at 13:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .