At a recent service management event I met up with a friend who is a problem manager, and as practitioners do, they tend to vent about one issue that they are facing in their organization. We started talking about a problem record that they had open and how it seemed it was never going to be closed off. Digging a little deeper, I asked why it was still open.
“You know…the root cause of this issue is still unknown. The workaround is holding it together. In fact, the customers don’t even think that this is a workaround, they think the app is supposed to function this way.”
I could tell that this was going to be a discussion which was longer than one pint of Guinness. I motioned to the bartender to get the next pint going…
Over the next while I learned the following about this problem:
- The application was purchased OTS (off the shelf).
- The IT project manager was instructed by the business stakeholders to have the application modified to fit their current process.
- Before the launch there were several issues identified; however, the business did not identify them as critical, so the application was rolled out on schedule with the business assuming the risk.
- In the first weeks of sustainment it was identified that there were more than a few “glitches.” The sustainment team made a list of the issues, created known error records in an Excel spreadsheet, and passed them along to the operational team.
I know what you’re thinking… first, wasn’t this a discussion about problem management? And second, there is a whole lot more going on here than problem management issues.
The answer is “Correct” on both counts. What if I also told you that the application we are talking about was launched 3 years ago? Here’s where this changes things a bit:
The application was OTS: The original OTS was so bastardized that the regular releases were not followed, impacting vendor support.
The IT project manager was instructed by the business stakeholders to have the application modified to fit their current process: The people responsible for this deployment have all since moved on to other companies.
The business did not identify pre-launch issues as critical, so the application was rolled out on schedule: The defects that remain have been in existence for three years since the rollout, and while still on a ‘list’ are not actively being reviewed or addressed.
The sustainment team made a list of the issues, created known error records in an Excel spreadsheet, and passed them along to the operational team: These issues are the problem records that have since been opened.
Because of the lack of improvement, or that workarounds have simply become the way to do things, the business is now facing some additional challenges such as:
- The application experience is bad as the defects have existed since rollout.
- The ability to correct the defects is impacted by an inability to move to new releases from lack of vendor support.
- Additional business concerns have arisen that these fixes will make things worse (loop back to customer experience).
Understanding whether or not this problem can be fixed is important, especially when the business determines that the cost of making the fix does not outweigh the incidents that are experienced. As we gain clarity on all the moving parts, we position ourselves to be able to learn from our past mistakes. As part of closing the problem record, a review which encompasses all this information should be completed and shared with all the vested parties, including (but not limited to) key business stakeholders, PMO, and IT Operations.
In addition to addressing the issue(s) as they exist, it should also be decided what actions should be initiated to prevent an issue of this type from happening again. Discussion of these problems is great, but we need to ensure that there is a component that actively works to make these improvements a reality so that we can avoid a problem record that is open for over 1000 days.
For more brilliant insights, check out Ryan’s blog: Service Management Journey