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.

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.

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.

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.

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.

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.

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.