Software Maintenance as PM - root cause or fix

[BlueKiwi]

Dear fellow ITers,

Synopsis: should root cause analysis on a software defect stop when a bug is pinpointed, or when a proven fix is created?

I've been tasked with implementing problem management for a complex set of software services our organization depends on. I'm trying to follow the ITIL framework, but keep wondering if software maintenance (finding bugs & fixing them) fits or not. One of our goals is to assign a cost to each fix and allow our customer to allocate limited resources to those fixes that matter most.

For example, can you really find a root cause (usually a defect) and then do an accurate estimate without actually testing a fix? Sometimes you may find the root cause and the fix is as simple as changing a constant in the code. At other times it may be a complex set of conditions under which a certain piece of code gives the incorrect result - but that code works for 99 other use cases. Root cause analysis can take some time, and you can't really say you have a good proposed fix until you write it and regression test the code. In such a case, should you stop, risk an estimate, and go back to the customer before you write a fix? If you don't you may end up spending a lot of time testing a fix to a problem which the customer might say wasn't worth that much time to fix.

1. Have you found it practical to identify a location of a bug, and then do estimates to fix it, before testing a fix?

2. Is a problem a Known Error once the root-cause is found and a workaround proposed - before a permanent fix is found or applied?

I'd appreciate any input from those who are using ITIL methodologies on software maintenance. I've been told it fits, but I'm not quite sure.

[UKVIKING]

You have to go outside the box

You need software development lifecycle and defect management - not in ITIL

here is the flow

Application is LIVE
A user finds a fault - Incident raised
the incident is examined whether it is a fault, user error (operator headspace / needs training), performing as function.

If it is a fault, then IM needs to restore service.. if NOT, IM ticket stays open unless there is work around
If it is a fault, then it has to be looked at by PM or Applicaton support to determine whether this is a Bug fix to resolve or a fix that will be dealt with when the new version comes in (design and build)

Then PM pushes this to the correct development

The IM ticket remains open (inactive or whatever) as the service is not working.
the PM ticket remains open until fix is deployed

the app dev team develops the fix or release
tests the fix / release
goes to CM Board
deploys
verifies and closes all related PM/ IMs
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter