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

Current Membership

Latest: ChelseaZ80
New Today: 46
New Yesterday: 97
Overall: 149994

People Online:
Visitors: 46
Members: 2
Total: 48 .

Languages
Select Interface Language:


Major ITIL Portals
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

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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 - Request for Change
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Request for Change

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
davetazz
Newbie
Newbie


Joined: Dec 28, 2006
Posts: 3

PostPosted: Thu Jan 18, 2007 3:29 am    Post subject: Request for Change Reply with quote

I work for a large organization. We have several different groups responsible for Development for new applications and fixes to the exisiting systems we already in place.

We have no way to formally request a fix or new application other than submitting a Magic Service Desk trouble ticket or work order. The problem with that is we have way to track the status of in in conjuction with the other request/issues that have been submitted to see what priority our request or issue been assigned in the overall scheme of things. No way to know when it will be completed, ensure the timeline is adhered to to to know who specificially is working it.

Wasn't sure if such requests should go through a PCR instead and if so what the process would be. Looking for ways to streamline all our request/issues that come into our development teams.
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3321
Location: London, UK

PostPosted: Thu Jan 18, 2007 7:27 am    Post subject: Reply with quote

Sounds like you need Release Management as well as Change management
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Guerino1
Senior Itiler


Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Thu Jan 18, 2007 11:22 am    Post subject: Reply with quote

Hi Dave,

ITIL is formally not intended to address "development". However, there are concepts of it, that can successfully fit and align with development. We do this all the time for companies that are interested. It usually comes down to understanding terminology and processes.

If you break down what Developers track, in detail, you will find that what they're typically addressing are "Requirements", "Defects", and "Risks". Many developers will lump these into a concept called "Issues", but if you break it down, you will see that it really is about handling four concepts:

  • What is new = Requirements (Explicit Requirement)
  • What seems to be broken but hasn't been proven, yet = Incidents
  • What is broken = Defects or Problems (Implicit Requirement)
  • What you're tryiing to avoid = Risks (Implicit Requirement)

Whether anyone wants to admit to this or not, it is actually very accurate and developers worry about these things every day. They were doing it long before ITIL was in place and possibly do it even better than how ITIL specifies to handle such topics. The issue is that most developers don't use the same terminology and, therefore, don't know that they're doing this.

Now, as part of the "Product Management" process, developers will plan for individual Releases, where they will uptick the version label of the Release and plan for what work will be done in the Release. The work, based on weighing the priorities of the organization vs. available resources, is what will be addressed in the Release. Therefore, if you read "Release Notes" you will find:

  • What new features have been implemented
  • What things were broken that have been fixed
  • NOTE: You will not typically find things about Incidents and Risks in Release Notes.


Now, to get to your original question about how to properly track and manage such work, you need to understand that ITIL and Development are pretty much at odds with each other. ITIL exists to address the livelihood of the production environment and took nothing from development into consideration when it was specified. As a result, it lacks a great deal of what developers need, in order to do their jobs, thoroughly.

For example, in ITIL, the goal is to try and get all Incidents to come in through your Service Desk and escalated through a controlled single process. However, in Development, Incidents come from many different stakeholders, in many different environments, and the Developers need to move very fast to address everything.

What we've found that works well is to have all Incidents, Problems, Risks, and Requirements logged and managed in a common system, where they are logged directly against the appropriate Products and/or Releases, and are routed directly to the Development and Engineering teams (a.k.a. the Product Management teams) that "own" and are accountable for the Products (and/or Services). This should be the same system the developers work from.

If you don't do this, your developers will do whatever they wish, in order to manage their work their way. After all, you exist because of them and as a delegate for them. And, while ITIL doesn't tell you this, your leadership does understand this. Dev teams will exploit this if you're not careful about working "with them" in a productive manner.

PS: A Release is nothing more than a "versioned" product. Release Management is the process of defining and managing a "version" of the product (a Release), through its entire "Release Lifecycle", which is a small subset of the entire "Product Lifecycle". A Release will be composed of one or more Changes, driven by one or more Requirements, Risks, and/or Problems. This is a critical discipline that developers impose on themselves that infrastructure resources following ITIL tend not to practice. Change Management, to a developer, means managing a "Change" to one or more Configuration Items, through the lifecycle of a Release. It doesn't matter what ITIL does or doesn't tell you to do. Developers have been following these concepts for decades and will continue to do so, so you will have to work with them, closely, to be successful. Unfortunately, too many people implement ITIL blindly, not thinking of these things until it's far too late.

Anyhow, I hope this helps.

Best Regards,

Frank
_________________
[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Thu Jan 18, 2007 11:27 pm    Post subject: Re: Request for Change Reply with quote

davetazz wrote:
I work for a large organization. We have several different groups responsible for Development for new applications and fixes to the existing systems we already in place.

We have no way to formally request a fix or new application other than submitting a Magic Service Desk trouble ticket or work order. The problem with that is we have way to track the status of in in conjunction with the other request/issues that have been submitted to see what priority our request or issue been assigned in the overall scheme of things. No way to know when it will be completed, ensure the time line is adhered to to to know who specifically is working it.

Wasn't sure if such requests should go through a PCR instead and if so what the process would be. Looking for ways to streamline all our request/issues that come into our development teams.


I have been in a similar situation where there was no team tool available to track application defect or enhancement requests. The Dev group decided to use the Incident Management tool as a communication vehicle (since it did a wonderful job of emailing the group members) to track the request. The way it worked in practice was there was several groups setup such as: AppDev, AppTest, AppQA, AppRelease. As the enhancement/bug went through its lifecycle, the group would assign the Incident ticket to the appropriate group.

It actually worked fairly well to track the progress of individual requests. The issue was that their AppDev enhancement records were skewing the Incident data. The way around it was for the AppDev team to use a very specific Categorization for their requests. During reporting against the Incident data, their Categories were excluded.
Back to top
View user's profile
davetazz
Newbie
Newbie


Joined: Dec 28, 2006
Posts: 3

PostPosted: Fri Jan 19, 2007 4:51 am    Post subject: Reply with quote

Thanks for the info, however I'm still trying to figure out what process or technology we can use to submit a request to the development team in order to get it approved, assigned a proiority and resources so that if I go into the system I can see what is currently in their queue and where mine is in comparison.
Back to top
View user's profile
dboylan
Senior Itiler


Joined: Jan 03, 2007
Posts: 189
Location: Redmond, WA

PostPosted: Fri Jan 19, 2007 5:20 am    Post subject: Reply with quote

Again, this is an inappropriate use of the Incident Management system, but you could set up assignment groups for BugSubmitted, BugReviewed, BugFixScoped, BugFixAssigned, BugFixApproved, BugFixTested, etc.

The time stamps of group assignment changes would give you the performance metrics and the group assigned to would show you where in process a bug or enhancement request currently resides.

A better solution would be to get a true Application Bug/Enhancment tracking application. If you do a Google search on "GPL Bug Track" you can find quite a few free applications.
Back to top
View user's profile
matrejekm
Itiler


Joined: May 11, 2006
Posts: 32

PostPosted: Thu Jan 25, 2007 6:20 pm    Post subject: Reply with quote

I work in that field and use MOF/ITIL to it - it works great.

Requests for Changes in applications comes either as a separate requests (new application, new business requirement, improvement idea), from Incident Management (applicaiton change is a way to correct an Incident) or Problem Management.

We use the same ticketing system, but RfCs are marked specially and a DOC RfC form is attached.

CAB is reviewing RfCs to applications (nowadays - all RfCs against application code). After approval it goes through development process and ITIL is greatly connected to development by using PRINCE2 or other Project Management methodology. At the end we have new release prepared and changes applied into produciton environment.

Our product version in CVS changes and also the CI description (application is a CI fo us) in CMDB.

It works very well!
Back to top
View user's profile Send e-mail
raroa
Senior Itiler


Joined: Dec 05, 2006
Posts: 54

PostPosted: Fri Feb 02, 2007 8:21 pm    Post subject: Reply with quote

You often end up with two parallel systems: Service Desk and Bug/Fix/SDLC. SD is used by the organisation as a whole to track the existence of a bug as a Problem, and the implementation of a fix as a Change. Likewise SD tracks the user request for an enhancement as a RFC and the implementation of the Change. So the SD is where you would track your current status, prioritisation etc. It is the business system

In parallel with this, the developers may have their own technical system that tracks affected modules, code revisions, versioning and packaging, vendor patches etc etc Problems provide bug input. RFC s provide enhancement input. Output is status change on Changes to go to production. It is the geek system

the geeek system is a peripheral or ancillliary system where a subset of problems and changes go during one step in their workflow, when the geeks decide they need to in order to be put through a technical lifecycle. During that whole cycle there is little or no activity in the corresponding SD entity other than periodic status updates

Some sites (and vendors) automate the integration between the two. I think this is unnecessary and in fact counter-productive. there is a translation step required as data flows between the two. the geek system says module ACD123 has been changed at line 75. The business sytem says the new shipping code has been added to the Warehousing service. The geeek system says your widget had the frammerjammer set to revert but we have grokked it and zapped the code table. the business system says it was a technical error but it is fixed now.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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 http://www.nukecops.com

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.