For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone
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.
The Itil Community Forum: Forums
ITIL :: View topic - Known Error without a Problem?
Joined: Sep 16, 2006 Posts: 3329 Location: London, UK
Posted: Tue May 06, 2008 8:41 pm Post subject:
My question back to you is as follows
A known error has to occur from some where.. chicken/egg
surely there is a incident/problem that this came from
that being said
the only known errors that I know of that does not require a problem record
are
Microsoft Windows 3.1 and the 640k memory issue
MS Windows 95
MS WIndows 98
MS WIndows NT 3.52
MS WIndows NT 4
MS WIndows 2000 Workstations
MS Windows 2000 Professional
MS WIndows XP
and the last one
MS Vista
and of course
Internet Explorer _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Tue May 06, 2008 8:51 pm Post subject:
... or to put it another way, an error is not a problem if it has no adverse effect, but then it can't really be an error either.
If you think you have found an error with no consequences and you are sure it is an error, then perhaps the problem you need to consider is how to find out what the consequences are. If you can't find any then reclassify the error as not an error.
After all why would you expend effort and resource finding a workaround and a fix for an error that was not costing you anything in the first place? _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
The reason I was asking this was, say for example the Product Development dept. just released a new version of a software, but due to time constraints, some things were missed out that not all, but some people may require. So they come up with a patch to overcome that issue. It was decided that this issue will be overcome in the next release.
Now I can store this information as a known error so that service desk knows what to do when a user calls in. my question is, Should I still create a Problem Record for this and then associate it to a known error or just create a known error record.
Also, another thing that has me confused is that does every problem has to have a known error record before it is resolved or a permanent fix can be applied to close the problem without it ever becoming a known error?
Joined: Sep 16, 2006 Posts: 3329 Location: London, UK
Posted: Tue May 06, 2008 11:56 pm Post subject:
that is not a known error or a problem mgmt area
that is product development
that is software mgmt
a different kettle of fish tobe honest
the release package... what ever it contains is the new version
if the s/w development team does not have a feature/upgrade list this should be their first concern
Software bugs/hidden features etc are not really known errors - unless you act as the repository for the software and the s/w dev/ & support team _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Mar 31, 2008 Posts: 109 Location: North West England
Posted: Wed May 07, 2008 1:23 am Post subject:
Oyeeeee wrote:
Also, another thing that has me confused is that does every problem has to have a known error record before it is resolved or a permanent fix can be applied to close the problem without it ever becoming a known error?
A problem becomes a known error when you have identified it's root cause and have a workaround. Therefore, how can you resolve a problem without first knowing it's root cause? Even if the problem seems to have been resovled as a side effect of another change, you can't be sure that the problem has been 100% resolved if you don't know what caused it in the first place.
Hope that helps _________________ Mick Smith
Change, Configuration and Release Manager
Joined: Sep 16, 2006 Posts: 3329 Location: London, UK
Posted: Wed May 07, 2008 5:26 pm Post subject:
If proactive PM finds a 'problem' / known error, it probably will create a problem record for it then register the known error _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
I agree with Viking: the problem you're describing is a process issue to be handled within either your standard SDLC or a particular project and it's management.
You can have an error without a problem e.g. font colour is wrong. Esthetics don't always get logged. No log => No problem. Go to the pub instead.
UJ _________________ Did I just say that out loud?
Joined: Mar 04, 2008 Posts: 1884 Location: Newcastle-under-Lyme
Posted: Wed May 07, 2008 7:46 pm Post subject:
Hi,
Oyeeeee wrote:
just released a new version of a software, but due to time constraints, some things were missed out that not all, but some people may require.
John is absolutely correct. The product should have been issued with the (unexpected) functional constraints fully documented for the user and a subsequent release would provide additional (but late!) functionality. Your service desk should be able to refer users who enquire to the documentation. It is not a service issue, it is a product issue. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Thu May 08, 2008 2:41 am Post subject:
To follow up
Oyeeeee wrote:
The reason I was asking this was, say for example the Product Development dept. just released a new version of a software, but due to time constraints, some things were missed out that not all, but some people may require. So they come up with a patch to overcome that issue. It was decided that this issue will be overcome in the next release.
Now I can store this information as a known error so that service desk knows what to do when a user calls in. my question is, Should I still create a Problem Record for this and then associate it to a known error or just create a known error record.
Sorry Oyeeeee, but I see that you misunderstood the idea.
Referring your post, I see this as the application lack in features.
A problem should refer to a service that runs improperly or abnormal. This means that the service has to be there to justify normal or abnormal.
Now, how could you detect a problem if the new application runs normally, it only short in promised features?
To me, this is definitely not a problem. It's just a normal upgrade.
One more thing:
Before the application was launched, shouldn't there be an User Acceptance Test and/or Certificate of Final Acceptance (COFA) that confirms the users that this and this and this would be installed in version 1, and so on and so on?
I am confused by the replies in this post
In looking at the ITIL V3 documentation, it states that a Known Error is
- a problem that has a documented Root Cause and Workaround
- Known Errors are managed by Problem Management and
* Known errors may also be identified by Development or Suppliers
In my understanding, issues are are to be released into production from development are to be documented as Known Errors
Joined: Oct 07, 2007 Posts: 441 Location: Jakarta, INA
Posted: Tue May 13, 2008 10:21 am Post subject:
mitter,
We are talking about functions or features not included in a release because of time constraint. This would not cause a problem when implemented and in production
What would happen is users complaining that they can't access the function.
This is not a known error, not in my view
You are right about the quoted statements but it should be elaborated more in relation with the circumstance of the case.
Let me give you an example.'
A new application has been developed, tested and ready to implement.
However, the dev. team realized that the application design takes large connection bandwidth. On testing, they can only test with, let's say, 20 conns. They know that if the number of conns increases to 100, it would have a significant impact on the bandwidth, and service will suffer.
The dev. team said that average conns are 60-70 but in peak season would increase to 90-110 (based on the functional requirement).
This, in my opinion, is a potential problem that could be registered as a known error
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
