Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: ejek15
New Today: 2
New Yesterday: 42
Overall: 231616

People Online:
Visitors: 127
Members: 1
Total: 128 .



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Problem versus project requirements
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Problem versus project requirements

Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message

Joined: Sep 14, 2009
Posts: 1
Location: Poland

PostPosted: Thu Sep 17, 2009 4:40 am    Post subject: Problem versus project requirements Reply with quote

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 Wink

Best regards,
Back to top
View user's profile Send e-mail

Joined: Aug 27, 2008
Posts: 10

PostPosted: Thu Sep 17, 2009 9:00 pm    Post subject: Reply with quote

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 Smile

good luck.
Back to top
View user's profile

Joined: Sep 14, 2009
Posts: 1

PostPosted: Fri Sep 18, 2009 8:11 am    Post subject: Reply with quote

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....
Back to top
View user's profile
Senior Itiler

Joined: Sep 21, 2006
Posts: 63
Location: USA

PostPosted: Sat Sep 19, 2009 3:05 am    Post subject: Reply with quote

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
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.