How Audit Trails and Traceability Mitigate Risk

[article]
Summary:

Traceability doesn't prevent errors and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools? On the contrary, audit trails and traceability are two of our most important CM tools for learning how to mitigate risk.

Any time we make a change to production, there is the risk that something will go wrong. Risk is a fact. The only way to eliminate risk is to never do anything. (But of course, that is not an option.) So we are left with actions we can take to mitigate those risks. Configuration management (CM) is mainly about risk mitigation. Everything we do in CM is designed to reduce the likelihood that things will go wrong, or to reduce the adverse impact when they do go wrong. CM helps us to avoid many failures, and to recover quickly from those few that we can't avoid. But how do audit trails and traceability fit into this picture? Traceability doesn't prevent errors, and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools?

On the contrary, audit trails and traceability are two of our most important CM tools for learning how to mitigate risk.

Answering Six Questions

Both auditing and traceability are mechanisms that are designed to answer the six questions: who, what, when, where, why, and how. For example:

  • Who made the change? Who authorized it? Who knew about it?
  • What exactly was changed? And what was not changed?
  • When was the change made (especially relative to other activities)?
  • Where was the change made (e.g. what platform, repository, location)?
  • Why was the change made? What triggered the change or motivated the person?
  • How was the change made? What precisely was done and not done? How was information about the change captured and communicated?

Although it is tempting to use these six questions to place blame, doing so can actually be counterproductive! It is better to use this information to learn about how we handle changes and what we can do to make them go more smoothly in the future.

Learning from "Who?"

The "who" of change primarily revolves around the availability of pertinent information. Were the "right" people involved? Did the person who made the change have the information that was necessary to make an informed choice about doing it? The same question can be asked about the person who approved the change.

And because any change can impact on other activities, a similar question can be posed. Did the people to whom this change was pertinent know about it when they needed that information?

About the author

Alan S. Koch's picture Alan S. Koch

Alan S. Koch, PMP, author of Agile Software Development: Evaluating the Methods for your Organization, speaks, writes, and consults on effective Project Management. Visit http://www.ASKProcess.com to learn how to improve the return on your software investment by focusing on the quality of both your software products and the processes you use to development them.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09