I feel that the added detail level in ITIL 3 are conflicting with things in RUP. In ITIL3, Service Transition, there are for instance a test and validation chapter which adresses activities that directly affects how and what a development project have to plan their work. That work is controlled by RUP. Any experiences or recommendations?

I wondered what RUP was .. lo and behold I went to yahoo and used search... who would have thunk that seaches actually can be used if you dont know the answer

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003

ITIL is not for software development per se. What it is for IT departments to manage their operational and soon to be operational (v3) processes so that IT can be managed in accordance w/Best Practice

In addition, despite the volumes of work dedicated to ITIL, it is NOT authoratative, it is referential in nature. TO implement ITIL is to implement BEst Practice

If it is best practice to use RUP or CMMI for the application development team before the release of the internally developed products into the live environemtn, then that decision woudl be Best Practice for that particular endevour

However, once the product is going to released into the live environment, then ITIL Best Practices for Operational IT Change, Release, COnfiguration etc - would apply

As to explore RUP and ITIL.. as I am not in an envir0onment where RUP or CMMI is needed, then there is no need for me

Just like a carpenter who may need a painter - if I need it, I will get the individuals who do it or learn about it_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

Hi and thank you for the answer!
I must admit that I am a bit surprised that RUP is not mentioned in relation to ITIL on this site since making change to a software application would be a common event affecting applications in production. I can see that it is up to the company to decide what is indeed best practise for them. The problem is that several recommendations from ITIL, RUP and other experiences collide and it such situations it is good to know how others have managed such overlaps instead of making the mistakes yourself. Is ITIL always the best best practise?
I think my question really is how to compare potential best practises without having to actually having to make the mistakes in order to make the decision?

ITIL is 'a' best practice framework. You don't have to use it if you've got another that's more suitable to your organisation.

Having said that it tends to sit at a higher, macro, level than say a SDLC framework, as John says ITIL assumes you'd incorporate such things at the appropriate point. So you can argue the point of integration to be where ever you want it - where ever is right for your organisation.

I think there's an white paper on the integrations between application development and IITL by the OGC but I couldn't remember where I saw it... Maybe someone else here knows?

Yes, there is a whitepaper on ITIL and ASL (Application Service Library). The whitepaper can be downloaded from the OGC website. You could also check with the site from the ASL-BISL foundation (in Dutch and in English). They published the whitepaper together with OGC.

I got my ITIL3 foundation certification some weeks ago and now understand my own question in relation to ITIL. As I understand it ITIL focus on creating/maintaining the SERVICE as a package. When creating/changing a service none/one or many IT-projects can be involved which in a way puts RUP, as a single development IT-project methodolgy, out of the scope. Therefore it is logical that there is no direct reference to RUP or alike methodology.

When creating/changing a service none/one or many IT-projects can be involved which in a way puts RUP, as a single development IT-project methodolgy, out of the scope. Therefore it is logical that there is no direct reference to RUP or alike methodology.

/Eborn

I've been struggling with this same question this week. There are a couple related threads in the Change Management forum.

I think it would serve ITIL well (whomever it is that's publishing ITIL these days) to put project, program and portfolio management into context for some of the ITIL processes that act as interfaces to them. My thought is that they could simply draw a diagram that shows how those things outside of ITIL might interface with it. It doesn't have to be "written in stone", just noted that there are these other disciplines that could interact with the ITIL processes and the most likely places for those interactions to take place.

I think it would serve ITIL well ... to put project, program and portfolio management into context for some of the ITIL processes that act as interfaces to them.

I don't think that is possible or necessary. Everything is too general at that level to be useful. Properly conducted projects will engage with whatever business processes (including ITIL derived processes) as they see them in the context of the project.

Whether that means hooking into the processes, following the same (or modified) procedures within the limits of the project scope or just submitting service and change requests as needed, all this will simply depend on what the project is and how best to manage it .

I don't see how to be more specific than that except in a particular case. There should be nothing frightening to an ITIL guided service organization when it comes to business projects._________________"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

I feel a bit dizzy about "bossy" issue. I don't see anything that would lead to who's boss and who's not.

I would like to point out 3 words in this context: project, development and operations.
Success is determined on how a company could make them run hand-in-hand and in harmony, based on its respective objectives, no matter what the tools they use. And one thing is keeping in mind the spirit of helping each other
Overlapping might happen, but that's the challenge to resolve.