Keith Posted June 20, 2018 Share Posted June 20, 2018 There is a gap in visibility of problems in relation to incidents raised by me as a Hornbill customer. I raised an incident on 15/5 which was promptly marked as "resolved" with an explanation that this is a known problem with no current ETA. The specific problem was PM00151247 which to my knowledge has still not as yet been resolved. As a result my Incident is NOT resolved despite being flagged as such and I have no visibility to the problem other than being advised to watch for a specifc fix appearing in some currently unknown future release. All the while the incident raised by my customer remains open impacting my SLA's and reputation. If I don't check the release notes I am unaware that my problem is solved. I'm sorry to say this just isn't good enough. I need better visibility as to how my issue is being resolved and what the ETA is. Keith Link to comment Share on other sites More sharing options...
Guest Paul Davis Posted June 20, 2018 Share Posted June 20, 2018 Hi @Keith , Sounds like something went very wrong here. I'll look into this and get back with a more detailed reply by close of business. Link to comment Share on other sites More sharing options...
Keith Posted June 20, 2018 Author Share Posted June 20, 2018 Thanks @Paul Davis, would appreciate some feedback on the process. Link to comment Share on other sites More sharing options...
Guest Paul Davis Posted June 20, 2018 Share Posted June 20, 2018 Hi @Keith, following up on the earlier comment with an update at the end of the day. I am still reviewing this with the team and will also post back with the clarification requested. Obviously, there is also the small matter of the defect you are referring to and I'll review its status with Development. Link to comment Share on other sites More sharing options...
Keith Posted June 21, 2018 Author Share Posted June 21, 2018 Ok @Paul Davis look forward to further feedback. Link to comment Share on other sites More sharing options...
Guest Paul Davis Posted July 11, 2018 Share Posted July 11, 2018 Hi again @Keith I’m getting back to you in relation to your question about our process and also to provide an update with the particular defect at the heart of this post. I would also like to thank you for the feedback. It has helped us refine what we do and is a good example of how we, at Team Hornbill, can leverage the community forums to provide a better service As I am sure everyone who reads this discussion appreciates, where software is involved, providing an accurate timeframe for the resolution of a defect can often prove to be notoriously difficult. In part, this is due to the complexities involved, but also estimation is, in my experience, not a skill that developer’s typically excel at. As a result, estimates are usually either hopelessly optimistic or with so much padding that they are of little to no value. We have up until now relied on our ability to turn issues around very quickly, helped by our agile approach to software development. However, I do appreciate that sometimes, as in this case, this leaves an expectation gap for the customer. In terms of new feature development, we only commit to new features when we add them to our 90-day queue. For customers with an Enhanced Success Plan, you can review the 90-day queue for Service Manager on the Success Portal. These customers can also see published defects, indicate that they are also affected and will soon be able to see a status which indicates progress on each. In addition to this, we have reviewed our support process and for those with an Enhanced Success Plan will also now be indicating not just the defect reference to find on the Success Portal as we do now, but also its priority and the average time to delivery for defects of the same priority over the last 90-days. The average time to delivery of recent defects is an observed metric and so I believe will prove to be more useful than any estimate that might be provided. For critical issues, there will of course be additional and more regular feedback. I hope these improvements put your mind to rest on this matter and again would like to thank you for your feedback. Keep it coming! Paul Link to comment Share on other sites More sharing options...
Keith Posted July 19, 2018 Author Share Posted July 19, 2018 Hi @Paul Davis , apologies for the delayed response. I was sure I had replied but clearly not I appreciate you and the team reviewing your processes and trying to affect change for the better of your customer base. I just want to make it clear that in my request for visibility I was not pushing for a resolution timeframe or prioritization within your development queue. My concern was that incidents raised which relate to a product defect were being marked as resolved when if fact no "real" resolution to my issue had been provided. At this point of resolution, I lost visibility of the issue and ability to correspond with Hornbill on the topic. Hopefully, the changes being implemented (are they in place yet) will have a positive effect and provide more incite and status as to the current state of my issues. Regards Keith Link to comment Share on other sites More sharing options...
Victor Posted July 24, 2018 Share Posted July 24, 2018 @Keith just to clarify the aspect of "no resolution to the issue" - When you raise a support request with us and following our investigation we (support team) identify the issue as being a defect, this represents the resolution to the support request. It is not always possible for our support team to fix the issue you raised (which is what you actually need) when that issue is caused by a product defect. However, being a product defect it means there is nothing more our support team can do on that support request (so we close it) as the issue needs to be sorted by our development team. You are right however, there was a mix of poor communication and not enough visibility/information following the conclusion of the support team investigation and the actual fix for the issue you reported, something we have been working to improve. Some (of the) changes are now in place on the "Published Defects" list on our portal: https://success.hornbill.com/hornbill/servicemanager/service/2/known-issues/ Link to comment Share on other sites More sharing options...
Keith Posted July 25, 2018 Author Share Posted July 25, 2018 @Victor thanks for the explanation. I fully understand what you're doing (and possibly why). My point though was that from a "customer" perspective the issue is not resolved. In simple terms the customer has an issue that needs fixing, they don't care who needs to fix it, they just want the system to work correctly. Using your approach I should close my incident with my Leica side customer because I and my support team can't resolve the issue. So, I'd mark my request as resolved and open a request with you. Clearly, this doesn't help the "real" customer. Possibly a better solution would be for you to keep your incident open until a full resolution is forthcoming (this is a defect, not a development request). The closure of your problem/change request could close the linked incident automatically. I get that you won't want to do this as you don't want any overhead managing these incidents or impact on your SLA's. BTW the request that triggered this discussion is still not solved and is not on your published defects list. In the meantime, the incident raised by "my" customer is still open on our side Link to comment Share on other sites More sharing options...
Victor Posted July 25, 2018 Share Posted July 25, 2018 @Keith 13 minutes ago, Keith said: from a "customer" perspective the issue is not resolved. I fully agree with this, and you are right, you should not care who needs to fix something, this is our problem, not yours 15 minutes ago, Keith said: Possibly a better solution would be for you to keep your incident open until a full resolution is forthcoming (this is a defect, not a development request) I'll try and explain my above statement. In case of defects, from the moment you raise a support request to the moment the issue is actually fixed, you could look at our support process as comprised of two stages in your support request lifetime: S1: your support request is an incident and is investigated as such by our support team and we provide you with an incident reference. Once the support team completes the investigation and concludes the issue you raised in the support request is a product defect then your support request is "transformed" from an incident into a problem, incident is then closed and your support request moves to it's second stage S2: your support request is now a problem and is being investigated and fixed by our development team and we provide you with a problem reference. Once the development team completes the fix then this is deployed in live instances and only then the issue you raised in the support request is actually resolved and fixed. If the above is followed then you will always have a reference for the issue you raised in your support request therefore you can track the progress to the resolution/fix of the issue you raised. You see then it won't be actually necessary for the incident to remain open. In the end all you need to know, I think, is when/how/where the issue is fixed and you should not be an issue for you(?) if we communicate to you form an incident or from a problem. Support requests that do not constitute defects, will not go into the second stage, they will be completed within the first stage. I do agree that the "second stage" mentioned above could be improved (which we are working on) and the spark that triggered this thread was the poor handling from our side of this second stage (when the incident becomes a problem). So, to clarify this: 29 minutes ago, Keith said: Using your approach I should close my incident with my Leica side customer because I and my support team can't resolve the issue. Yes, you could do this but only if your process allows the support request to continue to exist in some shape or form. If your customer's support request spends its entire life as an incident then yes, you should not close it until the support request is complete (in case of defects the issue being fixed). 33 minutes ago, Keith said: BTW the request that triggered this discussion is still not solved and is not on your published defects list. I'll have a look at this... Link to comment Share on other sites More sharing options...
Keith Posted July 25, 2018 Author Share Posted July 25, 2018 @Victor I totally understand how you're operating in terms of the two-stage approach and the handoff to the development team. 29 minutes ago, Victor said: S2: your support request is now a problem and is being investigated and fixed by our development team and we provide you with a problem reference. Once the development team completes the fix then this is deployed in live instances and only then the issue you raised in the support request is actually resolved and fixed. If the above is followed then you will always have a reference for the issue you raised in your support request therefore you can track the progress to the resolution/fix of the issue you raised. You see then it won't be actually necessary for the incident to remain open. In the end all you need to know, I think, is when/how/where the issue is fixed and you should not be an issue for you(?) if we communicate to you form an incident or from a problem. 2 In resolving the incident I am provided with a problem reference which, in theory, I can now track online in the problem tracker (though again in this instance I can still not see it). I can also see it referenced in the release notes of a new release. But, I now have no open dialogue on the problem. There is no channel of communication between me and the development team should they or I need further input or examples. The onus is now clearly on me, the customer, to monitor and track the situation and essentially I have no means to provide updates on the situation to my customer other than to advise its still in your development queue. I know your taking steps to try and improve the situation and I understand why you work the way you do. I'm just trying to illustrate this from a customer perspective. Link to comment Share on other sites More sharing options...
Victor Posted July 25, 2018 Share Posted July 25, 2018 10 minutes ago, Keith said: But, I now have no open dialogue on the problem. Perhaps there is a misunderstanding here. I don't see a scenario where you would need an open dialog on the problem? Why would you need an open dialog? (not talking about S1) 11 minutes ago, Keith said: There is no channel of communication between me and the development team should they or I need further input or examples. You should not need any further communication with the dev team once support team has confirmed to you the defect. If you find yourself in need to communicate then it means we failed (in S1) to provide you with all the necessary information at the time we communicated the incident resolution. We would need to look into why this is the case. The point is, if my team does the job well, and if the "Published Defects" has all the information we need to be there, you should not be in need for such further communication (ideally). 13 minutes ago, Keith said: I have no means to provide updates on the situation to my customer other than to advise its still in your development queue. Information presented on the portal should be sufficient for you to assess the current status of the issue you raised (once is a defect). Even if you contact support we won't have any other update or information than what you would already know from the portal. What updates you customer might look for? Btw, my discussion here is to better understand your perspective and I am trying to clarify and misunderstanding in the off chance there might be any... For the record, I say again that there are still some areas to improve on our side in the "problem stage" for your needs for information to be fully satisfied... Link to comment Share on other sites More sharing options...
Keith Posted July 25, 2018 Author Share Posted July 25, 2018 14 minutes ago, Victor said: Perhaps there is a misunderstanding here. I don't see a scenario where you would need an open dialog on the problem? Why would you need an open dialog? (not talking about S1) From my perspective, as the customer, I want to be able to follow up on the issue to find out what the status is etc. Again using the example issue that started this conversation, what is the current status of the issue? When can I expect a resolution? etc. From your perspective as S1, you have told me what the issue is and whats causing the defect and that you have handed this over to your dev team. You assume this is enough. However, I believe as the service provider you should be keeping me, the customer, regularly updated on the issue. What benefit do I get from checking the published defects list currently? I know its a defect because you have told me that when you marked my request as resolved. I have no need to say I am affected because you know I am as you logged the problem on my behalf. What I really need to know is what is the status, what priority has my issue been given, has work begun on resolving it and what is the expected timeline for resolution. 33 minutes ago, Victor said: You should not need any further communication with the dev team once support team has confirmed to you the defect. If you find yourself in need to communicate then it means we failed (in S1) to provide you with all the necessary information at the time we communicated the incident resolution. We would need to look into why this is the case. The point is, if my team does the job well, and if the "Published Defects" has all the information we need to be there, you should not be in need for such further communication (ideally). I envisaged you may need further examples from me or steps to recreate the issue. If this is never the case then OK. 36 minutes ago, Victor said: nformation presented on the portal should be sufficient for you to assess the current status of the issue you raised (once is a defect). Even if you contact support we won't have any other update or information than what you would already know from the portal. What updates you customer might look for? By portal I presume you mean the published defects as I now have no request I can follow. In this specific case, my problem isn't even being reported in the published defects. Someone in the process (presumably now at S2) should be able to advise me where my issue stands in terms of priority and provide an estimated timeline. As it is currently, my issue is like a submarine which has taken a deep dive and I'll only see it again when it surfaces, assuming I'm looking out for it when it does. Link to comment Share on other sites More sharing options...
Victor Posted July 25, 2018 Share Posted July 25, 2018 Ok, now I think I understand we the apparent argument we have here ... You are talking about current status and I am talking about where I envisage we would be once the portal improvements are in place... in other words we are on two different timelines. So: When your support request incident is closed as a defect there shouldn't really be any need for us to contact you requesting more information about this but, obviously, you would need to know how the fix for the issue you reported is progressing past S1 (the incident stage) and we need keep you informed of this. I say again, that I do admit we do a rather poor job at the moment as the information presented/communicated for defects is not sufficient for you to effectively track the progress of the defect. Once we establish the defect, do you think this information would be sufficient for you to track the issue through the problem stage (S2)? problem request/defect reference - so you can easily find in the defects list presented on the portal; current problem/defect priority - which will give you a fix target time; current problem/defect status - we could potentially implement automatic notifications so you woudl know what the status has changed which should cater for the need/request of being kept updated on the issue (besides the status changes there aren't really any other updates we could send you on a defect... are they?) If this would not be enough for you to effectively track the issue resolution through the defect stage, what other information you would need? While we discussing how we should best support you going forward, I will have a look for your "submarine" Link to comment Share on other sites More sharing options...
Keith Posted July 25, 2018 Author Share Posted July 25, 2018 I agree it seems we are on different timelines but I can't comment on what I can't see currently I think you have summarised what I need well. The only thing I would possibly add to that is the ability to filter the published defect list by the problems that I am affected by (either raised as a result of my incident or where I manually flagged it as "I'm Affected") . 1 Link to comment Share on other sites More sharing options...
Keith Posted August 22, 2018 Author Share Posted August 22, 2018 Hi @Victor Seems my submarine still hasn't surfaced Anything you can do to provide an update? Link to comment Share on other sites More sharing options...
Victor Posted August 22, 2018 Share Posted August 22, 2018 @Keith uhh... yeah... I did not actually work on "resurfacing the submarine" (on my - now long - to do list). I'll have a look and get back to you... Link to comment Share on other sites More sharing options...
Victor Posted August 22, 2018 Share Posted August 22, 2018 @Keith - I have checked PM00151247 and is still being worked on... Link to comment Share on other sites More sharing options...
Keith Posted August 22, 2018 Author Share Posted August 22, 2018 OK @Victor , thanks for following up. I had hoped this was a fairly easy (and quick) fix. Link to comment Share on other sites More sharing options...
Victor Posted August 22, 2018 Share Posted August 22, 2018 @Keith - before I checked, the PM was marked as resolved (fixed in passing). This was done last week. Upon testing though I found the issue still occurs so I notified our dev team. Therefore, still being worked on... Link to comment Share on other sites More sharing options...
Keith Posted August 22, 2018 Author Share Posted August 22, 2018 OK @Victor , Thanks for the further info. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now