Problem Ownership: Take the Wheel
The single most critical factor that will determine the level of success and effectiveness in solving a problem lies within its definition, followed as a close second is the assignment of problem ownership.
A problem must be clearly identified in order to effectively create a solution. As simple as this may sound, often there is an immediate move into solution mode without a clear understanding or articulation on what is actually happening, typically running with a selection of assumptions and known quantities – more on that later. With the definition of an issue comes the requirement to assign levels of problem ownership.
Something is broken somewhere
I apologise in advance if this example appears a little low-level and slightly technical – I feel it happens from time to time at all levels within many given situations in an organisation. Some time ago, I signed up with an IT support team for a large company. During my second week working there, I received a phone call from John who worked within an indirectly related technology team advising me that something was broken, somewhere and he wasn’t sure what it was, but he assured me it was my problem, not his. All he really could tell me at the time was “something was broken somewhere” and he was “not sure what it is”.
As it turns out, whilst I had no idea about the underlying problem there was more information available within the ticket that John received, that he had not provided to me over the phone. It gave a source computer location (a computer that belonged to my department), an error log file name, and so on. I was able to trace what was wrong through the error log on “my” computer. The error file led me to make contact with more and more people I had not yet dealt with in the organization. I went around to various teams, introducing myself learning more and more about each underlying and interrelated part of a particular script that was running and generating this mysterious error. I feel it is important to note that I had no idea what this script was doing, I simply engaged other people and asked them to interpret what it was actually doing.
Finally, through the help of others that actually understood the script and associated program, I found the exact point at which this error was occurring. This discovery process took a number of weeks. The mysterious error was occurring because someone had deleted a user account that was hard coded within a particular program to send files over the Internet. The sent files, once received, were supposed to be used to print stock labels at a third party warehouse in another country. Without the labels, no stock could leave the warehouse in question overseas.
To rectify the situation, the deleted account and associated credentials were reinstated and the back-logged file transfers resumed. The mysterious error turned out to have been quite a big deal after all. No shipments had left an overseas warehouse in over four weeks.
The point of the story was that John did not provide enough information in order to fully understand the problem. With better and more descriptive information the problem could have been resolved sooner. In a perfect world, this kind of thing would be fully documented and known to relevent custodians around the business – in the real world, sometimes this does not happen – perhaps this is the real problem?
Initially, I had no idea as to what the underlying problem was – I merely relied on those around me who had the most appropriate low level technical knowledge to identify and correct the issue by proxy. In John’s situation, it was a knowledge transfer issue, combined with a level of ambivalence regarding the situation. Upon further investigation, the team that had originally created this process had left the business some time prior to this particular issue surfacing. John chose not to take ownership of the issue and distanced himself from the undefined problem. This situation would have snowballed for quite some time had no one made the choice to take on the problem ownership task and define the problem. It was only when a decision was made to understand what was occurring that we were able to begin defining the underlying problem and understanding the wider ramifications.
Problem Ownership – Going the extra mile
All too often, when a complex problem arises, it is not clear exactly where the lines of demarcation truly reside. In order to make the first step, it is sometimes necessary to take ownership of a problem that may appear to be beyond the confines of an individual’s role in an organization.
Given the example of John earlier, we can clearly see that had no one taken ownership, the issue may never have been resolved or even identified. Technically, with what was known at the time, the issue was not John’s responsibility, nor mine – it was SOMEBODY‘s issue. Somebody MUST make the decision somewhere to draw a line in the sand and take ownership. If presented with such a situation, in order to help make this decision easier, a Jigsolver may contend the following thoughts:
Right now, I may or may not understand exactly what this problem is, nor do I believe that it is my responsibility. Regardless, I will do my best to identify as much as I can and find or engage its most appropriate owner thereby assigning problem ownership. Until such time, I will become the caretaker of the situation.
It is important to remember that the person who initially takes ownership of the problem may not have the tools or know-how required to resolve an issue – they may have simply articulated relevant concerns and take the necessary steps required to engage the services of a relevant expert.
If no one is owning an issue and you have the capacity to do so and it is appropriate, don’t be afraid to show some initiative and take charge. Find out who can help and get the problem solved as soon as practicable – don’t let problem ownership bounce indefinitely between departments.
