It’s Not My Problem
It’s Not My Problem
By Meade Rubenstein
One of the major challenges of a project manager, or any manager, is determining who owns the problem. By default, the problem is owned by the person with the biggest guilt complex (aka me)…and not the person who can actually address the problem. No matter how hard the current problem owner tries to get others to help resolve the issue, the problem tends to bounce right back, as if it was attached like a paddleball. The end result: the problem is not effectively addressed and blame and future problems have a greater tendency to be associated with me.
Ok, rant over, now some definitions:
- The problem – anything that went wrong
- me – the person who always seems to be working through the teams problems
Without trying to over-define everything, let’s just say that the problem is something that needs to be corrected, is understood enough to know who it should be assigned to and is of a severity enough that it needs to take priority. Any additional information is…well…nice to know.
An effective process would be:
- Centralizing problem reporting – an excel sheet to some sophisticated bug tracker
- Problem Triage – someone (me) needs to determine how severe the issue is and who the person is that is most associated with it and can resolve it
- Assign (you need authority) to the person
- Follow up and make sure the problem gets attention and resolved
Seems simple, but if you assume people understand the process and will voluntarily follow it…well let’s just not assume, let’s communicate to the team and to management and let us assume that we have the authority to push the problem to the right person… As difficult as assigning to the right person is, the actual resolution is based on the person’s focus and attention to the problem. The easiest way I’ve found for this to happen is to send out a daily/weekly report of all active problems, who they are assigned to, and how long they’ve been out standing. Peer pressure/management pressure can then take its course.
Meade Rubenstein has over 20 years of IT experience. He is currently the COO of Gráfica Group. Meade’s website can be found at http://www.itprojectguide.com/ and his personal blog can be found at http://www.itprojectguide.blogspot.com/.
One of the ways we work around this is to make sure our clients know who does what on our team right from the get go, then we give them the keys to the kingdom to work directly with the developer, designer, etc through issue resolution. Most of the time, there’s no need for the middle-man, pure and simple. Using products like DoneDone (to assign and manage issues and problems) and Basecamp help keep the broader team abreast of the many smaller discussions going on, which is to say, they alleviate the guilt cycle and bottlenecking you mention.
Good thoughts in the article, although very basic things, but still problems arise and no one makes an effort to resolve them. I think part of it is ownership problem. People are afraid to own a problem in the absence of complete support and authority. Hence the problem resolution is left to a lone crusader who cannot stand them and hence other people tend not to stand for that person :-)