//
you're reading...

Career

A Dilbert’s way on submitting enhancement requests

I’ve learned something Dilbert-y at the office very recently. If you want to get your enhancements or bug fixes done by the development team then you need to make those requests as justifications for business travel. My list of bug fixes request have been pending for more than a year until a big guy from London traveled to Singapore and then asked us if there are any problems here. I gave him some of the issues that have been nagging me and voila, he gets someone to fix those after he got back. My guess is that he made those fixes as his business justification for traveling so that he can say that his travel was “productive” because it “resolved 2nd line issues”.

Some background to the story may be in order. I work as a 2nd line IT support in a bank. We support a particular set of mostly in-house applications (those that the bank built by itself and not buy from outside) and our scope of work is troubleshooting data loads and issues that could not be resolved from the application’s user interface (screen). We sit between the help desk that picks up the calls from the users and the development team that modifies the program based on bug fix or enhancement requests. As always work needs to be prioritized and so does the development team prioritizes their requests.

One of the things that I notice is that bugs that are raised usually gets fixed only if there is a business impact. That is if the end-users want them really bad and drives those bugs through their management levels and into our management levels. Additionally bugs that have a workaround tend to get ignored and stay in the system unfixed. Also the same goes for bugs that adds additional IT work for daily workaround but has no business impact as long as we keep doing that routine workaround. It’s pretty lame but hey in this tough times having a job is worth thanking for.

So the story goes that my “pet peeve” list of bugs tend to be those bugs that are workaround-able and adds an additional routine that we do every day. I’ve posted them to the development team more than a year ago via JIRA and notify them but they seem to ignore it. It’s understandable really since I’m not their boss and their boss is not pushing it — so why would they want to do additional work if not for their benefit?

The lesson learned is that IT-oriented bug fixes need to follow this process:

  1. Post a JIRA ticket to the development team detailing the bug and what solution that we want.
  2. Wait until we collect at least five of these tickets.
  3. Ask the bosses of the development team (each part of the application stack has their own team and thus their own boss) whether they would like to travel to Singapore. Suggest these JIRA tickets as their business travel justification.
  4. Spend about an hour discussing those tickets face-to-face when they arrive. It doesn’t really matter how long that boss is scheduled to stay.
  5. Update the JIRA tickets individually based on the discussion if necessary.
  6. Send an e-mail about that meeting’s result and detail the JIRA ticket numbers with it. Copy their team (including the boss) and our team.
  7. About a week after the boss came back to his/her home country, remind him/her and the team about those JIRA tickets.
  8. The boss should be able to find someone to look into your bug/enhancement requests.

    As I said earlier, there’s something very Dilbert-y about this but can’t really pinpoint where. Any comments?



    Do you enjoy this post? Enter your e-mail address below to receive articles like this one in your mailbox.
    * indicates required

    Discussion

    No comments yet.

    Leave a Reply

    Free Updates!

    Learn how to grow your indie business while keeping your day job.

    Categories

    Archives

    Keep updated!

    Don't miss out on new articles!