Problem versus project requirements

Discussion on issues related directly or largely to ITIL problem management.
Post Reply
User avatar
dave_go
Newbie
Newbie
Posts: 1
Joined: Sun Sep 13, 2009 8:00 pm
Location: Poland

Wed Sep 16, 2009 2:40 pm

Hi everyone ! I work for an IT organization and I'm a PM Process Analyst.

Let imagine a following situation with IT problem
during investigation phase we have a conclusion that this is not really a problem because requirements were not preciselly defined by Business side or there where no requirements regarding IT system behaviour in a very specific situation.

And of course end users call the ServiceDesk and say 'this should work in a different way' , ' this is not working because my order has stuck in this system'.
ServiceDesk of course raise a problem ticket and after that we have a conclusion that someone didn't predict this particular situation in IT system and there were no requirements for IT project regarding that.

What to do with this problem?

You know, cancelling maybe is not a best solution because end users satissfaction may fall and this is constantly monitored and my bonus is dependent on that factor.

Please let me know how do you solve that kind of situation, what kind of attempt you choose:
- cancelling and info to end users to raise a new requirement to the next project
- inform client (not user) and wait for his decision (is he willing to pay or not) - what with problem ticket then?
- direct contact to projects without business contribution
- cancell and forget method ;-)


Best regards,
dave


User avatar
bennyboy
Itiler
Itiler
Posts: 10
Joined: Tue Aug 26, 2008 8:00 pm

Thu Sep 17, 2009 7:00 am

In my humble view, the worst thing you can do is cancel the ticket and forget about it.

My approach would be to talk to the project team and:
1. let them know there is an issue and that users perception is negative
2. Find out from them what the original requirements were and if this issue has already been discussed with the client
3. Someone (Either you or projects) should inform the client, give them all the info they need to make an informed decision and your ticket will get it's conclusion one way or the other
4. Let the end user know that you're aware of the issue, it's being tackled and the decision will be the clients and not yours.

My 2p worth :)

good luck.
User avatar
Ting
Newbie
Newbie
Posts: 1
Joined: Sun Sep 13, 2009 8:00 pm

Thu Sep 17, 2009 6:11 pm

In addition to what Benny said, it would also be of some value, if you can, to identify or present a workaround for the user's issue - it may mean doing things manually but this will definitely leave a good impression on the quality of service being provided.

That's just me though....
User avatar
Marcel
Senior Itiler
Senior Itiler
Posts: 63
Joined: Wed Sep 20, 2006 8:00 pm
Location: USA

Fri Sep 18, 2009 1:05 pm

The fact that the application code does what it was designed to do does not mean that there is no problem. There is a problem, however the root cause (then tracked as a known error) lies in the requirements or in the design. As a result of this, there is a mismatch between system functionality and business process. Make sure you can categorize your known errors by the nature of the root cause (e.g. code bug, design flaw, missed requirement). If you find that you have a lot of problems relating to design flaws or missed requirements then there may be a reason to evaluate your system development approach to ensure better quality of deliverables.

We certainly have experience with such situations in our organization. Traditionally, developers are eager to classify such situations as 'enhancement requests' instead of 'problems'. Several examples that we had have helped convince people that that is not the right thing to do. If the omission of a certain function in the application drives dozens or even hundreds of calls per week to the service desk, then there is little question that these things need to be fixed.

Be cautious though. As much as I advocate the above approach, you need to be careful that Problem Mgmt does not become the process to track new business requirements. For example, the business may be changing their process and as a result they feel that an application no longer meets their needs. Or users may come up with some 'nice-to-have' requirements that did not make the cut in the original project. These things should flow through regular development/enhancement processes. Problem Mgmt should limit itself to those situations where the application does not adequately support the business process that is was built for. Obivously, the distinction between the various situations is not always cut and dry. Make sure to provide sufficient guidance on handling these situations in your organization.
Manager of Problem Management
Fortune 100 Company
ITIL Certified
Post Reply