ITIL & long project development

[cjmt]

Hi.
I’d like to include in my ITIL implementation all user’s requests for internal development of small/big software modules (e.g. SQL script to generate a specific report, a full web application for the intranet, etc).

Let’s say that there is a report that needs to be provided to an external entity by our accounting dept.
In a simplistic view, I would start by entering an incident such as “Unable to provide report to external entity”, then pass it on to PM which would provide the requirement analysis procedure that would take place so that requirements of the module can be defined.

Development could take several days or weeks (leaving the incident unsolved for a long time), then Change & Config. would take place and once the script would become available, tested, approved and go to production, the incident would be closed.

My post is about to get to know other's experience/opinions about the integration of ITIL with managing projects that can take a long time to complete and might not actually be related or dependant on the IT infrastructure.

Thanks.
Cristiano

[Mark-OLoughlin]

Hi,

back up there for a moment. Just becuse a report does not exist it is not an incident or a problem. Can you have an Incident or a Problem about something that does not exist - interseting !!

My view is that it is a request - a user or department want a new report. That takes time, money and effort to Develop no Resolve.

I would see the initial requirement get logged as a Service Request and go through chnage management before being put into the live system. I do not see the eed to engane incident and/or problem management for this.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant

[UrgentJensen]

Hello there,

Yes you must certainly not mix service requests together with incidents. You could certainly use the same tool to log them but they will have entirely separate metrics/escalations etc.

Incidents: restoring service

Service Request: asking for a defined service e.g. new blackberry or new starter accounts.

Good luck,

UJ
_________________
Did I just say that out loud?

(Beige badge)

[cjmt]

Thanks guys! It makes perfect sense.
I guess I didn't grasp the ITIL perspective on this.
So what could be the practical consequence of logging the two using the same tool? Statistics and reports might eventually get mixed if the tool doesn't allow intrinsically this distinction from the service desk interface, DYT?

Cheers,
Cristiano.

[UrgentJensen]

[Diarmid]

Hi,

a service desk can take in lots of kinds of calls. You need to be able to classify on at least two levels, whether you call these call types or categories or anything else.

The top level activates at the moment you receive the call and should contain something like:

incident report
service request
change request
information request

After that you break the call down to something useful for how you manage these classifications (not urgency - that's another type of classification which you also need).

Don't let the nomenclature in your software tools lead you astray from proper and meaningful classifications.
_________________
"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

[cjmt]

Diarmid,
Thanks, thats exactly the point to where I was going next, for I wasn't able, from the tool, to create a "classification" within each category. My initial thought is to try mapping the sub-categories as close as possible to the service catalog. Could this be an efficient approach?

Cheers.
Cristiano

[cjmt]

Please ignore my question about categorization, it is closely related to a previous post in the Service Desk forum (post: "Incident Classifications - Clarification").
Thanks all.

Cristiano