I'm managing a project to implement a new dialer software in our call center operations, but the IT Director is questioning if is really necessary to open tickets to report incidents (what is what i'm doing) related to the project product. For me, is much better to have a ticket number to watch and keep me updated about the resolution process.
It's wrong or at least a not good practice to open ticket to report incidents related to the project? Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
It is an excellent idea. Our IT provider for our company does this and it is a great source of tracking as well besides that it keeps the client satisfied as well. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Perhaps I did not get your point but what does means "report incidents related to the project product"?. If you are the project manager you will have activities related to verify and validate the project product. And you will have a system related to manage verification and validation results (change request, etc). But tickets about the project product is not a good idea. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
There are a few dimensions to your question, Bruno.
First of all, there is the notion "incident". When a help desk receives a call or email, they normally open up an incident ticket. That ticket will track time to capture and triage the incident. Once the incident is deemed to involve a supported product, a new "product" ticket is opened and usually assigned to Tier 2.
The second dimension is that of project versus operations. What I previously described is a typical operations incident. Usually, you don't open incident tickets in a project. You probably would open product tickets to deal with project issues and defects. For example, the Quality Control group would likely open defect tickets as part of their testing. Please note that "product" is a pretty generic label for anything produced by the project: deliverables, test cases, documentation, processes, ...
I have seen projects use tickets to track deliverable-related work. I do not agree with that use of tickets. It is enough that you have a project schedule and that you provide each team members with the assignments they should be working on.
Does your situation match any of the scenarios described above? Saving Changes...
Paolo CornaliProject Manager| HTA srlBrescia, Lombardia, Italy
Sorry, but I don't understand your question. Could you provide an example for what do you intend with incidents related to project product? Saving Changes...
When I say incident, i'm using the ITIL definition. We are in a pilot phase, using the solution in the real environment. Some existing functionalities started to present issues since then. For these issues, i'm opening incident tickets to our IT (that handles them to our third party partner that actually develops the product).
My intention is to keep track of all the issues. With tickets, they will not get lost in some inbox and the ticket number provides reference, since I need to report them to our customer. I think I can use them as metric also, monitoring the numbers of tickets opened to solve issues of the product, so we can enhance our testing and development processes (something like "how much problems with the software have we left pass?" or "how much problem did the software presented?").
We tested the functionalities before the pilot phase, but the errors we're facing are not directly related to the scope, they're indirectly related (like "functionality X, not in the project scope, presented issues after the change").
Did I clarified the situation? Let me know and thanks for the help so far!
...
1 reply by Paolo Cornali
Feb 17, 2016 12:45 AM
Paolo Cornali
...
Thanks for the clarification Bruno.
I believe that is a good practice maintain your internal log. If your IT Director doesn't want to use internal ticket for this purpose because it is an external product, use a spreadsheet. It worked fine for me in the past.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
My first comment is: if it works for you to achive a project objetive go ahead. I have been working in this type of environments and I will say: to open a ticket has nothing to be with the project. On the other side what the situation demostrate is that there is not a good project quality planning and that will impact your client acceptance. Sorry if I did not understand well. Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
If you're using the system in the live environment, then yes, I agree that using tickets is the best route. We don't use tickets when it's not live, and then quickly after live move to using tickets to track bugs, changes etc. Otherwise it's impossible to keep track of all the issues. When does he think you'll start using tickets if it isn't now? Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
As Elizabeth states, it is appropriate to track incidents in the live environment. Not only that, but you should record each and every instance of an incident. This will help determine the breadth and impact of the issue on the user community. (During the project, you only record one instance of the incident.) Saving Changes...
Since the dialer software is a third-party software, I agree that having some sort of internal tracking is important. If that is your company's incident tracking system, that's fine. If not, devise your own; a simple spreadsheet would work.
You should not completely rely on the call center vendor company to track *your* issues. Keep your own set of records and cross reference them to the vendor's tracking system, assuming you are provided with a reference number to their system when you report a problem. Saving Changes...
Project Incidents are not covered in ITIL. ITIL is more focused to operation and incidents are related to services that are in use by end user (functional) customers. I used to manage project issues (the closer event to an incident) in the issue log template. Saving Changes...
"Without question, the greatest invention in the history of mankind is beer. Oh, I grant you that the wheel was also a fine invention, but the wheel does not go nearly as well with pizza."
Community Champion
