Editing Change Requests On Behalf of a Requester
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-04-2025 05:45 PM
I am a contract change manager for a major metropolitan client. I am the one who is responsible for preparing each week's change requests for CAB review. I often find typos, punctuation errors, sentences that don't make sense, incomplete information, etc., and make corrections on behalf of the Requesters/Implementers. The company I represent has a change manager who always has the final say and says I should NOT do any of this but rather, send it back to the Requester/Implementer. I never add or remove content . . just corrections that allow the change to make sense. I asked if it would be OK if I received permission from a Requester/Implementer, in writing, to make updates and he said no. Am I violating any known best practice by performing some basic editing and/or updates? By sending changes back to NEW everytime I see small errors that I can easily correct really slows the approval process down and makes my job alot harder. Thoughts?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-05-2025 08:02 AM
Hello LeGar50,
having been in both your and your company's change manager shoes, I can give you my two cents about this. I tend to agree with your change manager. My reasoning is as follow:
1 - By making even small corrections, you might miss something that can change a meaning somewhere and result in errors down the road. Don't forget; as change manager, you are not the one who has the knowledge to do the technical job, so you are not the best one to judge if the text is right or wrong.
2 - It all come back to best practices and process maturity, the peoples writing these changes must be tougth to write clearly and accurately.
Yes, it will slow the approval process for a while but you will soon see improvment in how the CR are written.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-05-2025 08:31 AM
Pretty straight forward, has this been documented anywhere? Has any auditor verified with you if this practice is acceptable or not? Barring which, I would agree with Jean too, although you can log and audit the changes, do you really want to explain to auditors why you are making these changes for others?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-05-2025 08:44 AM
I agree with Jean's answer.
It is crucial that the requesters take the responsibility for the quality of the content otherwise they will never learn and will expect someone to fix their content all the time (or not even understand that you are actually doing that).
I see your point where you don't want to block a change for a small mistake, but if you continue to do it they will never improve, so they will have to feel a bit of pain and provide you with the correct information.
What you can do is, instead of fixing their mistakes, maybe you can just directly tell the user as soon as possible that their change will not be approved as long they don't improve their written content, after a couple of times it should come naturally.
Good luck !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-05-2025 08:50 AM
I totally get your frustration—constantly sending changes back for minor edits slows everything down and adds unnecessary admin work. In best-practice ITIL and ServiceNow Change Management, the official stance is that the Requester/Implementer should be responsible for their own change records, ensuring accuracy and completeness. However, in reality, many Change Managers do what you’re doing—making small, non-substantive corrections to keep things moving efficiently. The issue here is more about governance and accountability than actual best practices. Your company's Change Manager wants strict ownership with no edits from you, which is a rigid but technically defensible position. That said, it’s worth pushing for a middle ground—perhaps a documented process where you flag small corrections but still allow the Requester/Implementer to approve before CAB. If efficiency is the goal, there has to be some flexibility rather than bottlenecking changes over things like typos.