I don't think there is black and white answer. If you were able to mitigate immediate impact of the incident by providing a plausible workaround, you could potentially suspend the ticket, which would stop the SLA time on resolution, but won't stop the ticket from "aging". This is not always a preferred practice in cases where the user(s) is still experiencing the impact and don't have full access to the service.

I've seen organizations that actually close incident tickets that do have pending changes associated with them. From practical stand point, they will still resolve the issue, but it will make it harder to contact end users to validate resolution, and to track issue resolution in general in case as you state change takes too long to prepare and implement.

If anything, you should link incident tickets to change ticket to ensure that kind of traceability.

See what your policy says and most importantly investigate and think what makes most sense for the organization.

The only way to stop an incident ageing is to resolve it. The only other way is for its importance to the customer to drop to about zero so that the customer will accept closure without resolution. The only other way is to buy the customer off.

Suspending or stopping the clock is a means of having your management system disagree with reality. The more you do this the more difficult it is to determine whether you actually have a viable management system.

Resolving an incident is a matter of restoring the interrupted or impaired functionality to the customer's satisfaction. This can be by means of a fix or a workaround.

If the incident threatens an SLA on its own, then it is either an incident with severe impact (in which case you are not going to be wasting time worrying about SLA's because you will be too busy getting it fixed) or your SLA's are too tied to individual incidents and the SLAs should be repaired.

If the incident is going to be open so long that it impacts an SLA based on rolling averages, then that is what the SLA is for (and if that is your primary concern, the incident cannot be having much impact).

The message in all the above is that if you have got rules, stick to them and always discuss to the point of agreement with the customer exactly what you are going to do about a recalcitrant incident.

You can always propose that your SLAs have a clause under which incidents are excluded from counting towards penalty clauses (or adverse review findings) with the customer's agreement. You can always ask! _________________"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

Not sure what IM tool you are using. But, Remedy and the family has the option to stop the incident ageing by changing its status to 'Pending'--> 'Monitoring the Incident'. This actually stops the incident clock until the status is changed.

Are you able to discover and analyse incidents that had their clock stopped to determine if it was appropriate to stop it. are you still readily able to determine how long the service was unavailable/interrupted in real time?

Let's say the clock was stopped for a very good reason and with full agreement from the customer (not user). Is the fact sufficiently flagged to be picked up in review so that it can be considered whether the underlying reason for stopping the clock needs to be addressed.

Stopping the clock is such a dangerous idea that it should only be done if it is a subordinate clock because you should never lose track of how long an incident has been in an open state.

It might be better to take the heat over the SLA breach initially and negotiate it out at service review with the customer if there was good cause._________________"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

if a incident is created which demands a change to be created and let say this change will take time to resolve, till then should this incident be open

I guess answer would be yes.
If this is kind of routine thing which happens , what would be the better way to handle this without increasing aging time of tickets"

You are right in stating that the incident should be kept opened till the change cycle is completed. You further mentioned that this kind of routine things which happens. For me, the incidents would have a saving grace if you actually mean routine things. In case of routine issues, it would be safe to shift the focus to the problem management. For routine incidents, problem record should be created and RCA should be done. The change or no change would depend upon the RCA. It would be wise not to have such issues become a routine and get them fixed for good. The by-product is that is an incident is linked with the problem record lose its significance of aging. In such cases the age of problems matter and incidents take a back seat.