When Procedure is the Desired Result

When I started working here, there was an initiative to standardize access by job roles. On the surface, this is a fabulous idea.
It defines responsibilities and allows for smoother configuration of the accounts of new hires.
The problem is the transition.
Several people on my team have been with the company for a decade.
During that time, they have accumulated accesses they no longer need by definition but still use as a learned component of their day-to-day jobs.
My manager is one of these people, and since this whole project ties in with our groups role in the company, he has been tasked with making it happen even though it is something he does not want.
According to process, he assigned a project manager to the task and sat back.
This project manager diligently began documenting roles and responsibilities and access lists and submitting paperwork. The my manager found something else to take priority and pulled her off the access project to work on that.
He assigned another project manager to take over the access initiative. This project manager needed quite a bit of cross-training and catch-up information from the first, but once the transition was complete, he too began to document things and submit the proper forms to make this change a reality.
However, as frequently happens in large and complicated environments like this one, something came up. My manager pulled this project manager and set them against the new task, assigning another to replace him on the access standardization initiative.
Again, there was a period of cross-training and catch-up. This third project manager found some inconsistencies in the process which had existed from the start. She began the process of correcting these, starting with the beginning of the project timeline. Since some of the original requests are over a year old, they need to completely be re-submitted for review. Further, the error makes a good case for a re-evaluation of existing gathered data sets, prompting a review of those.
Closing his office door behind me, I asked my manager if he knew that the project had just been effectively rebooted, delaying the end result well past the deadline established in the project budget and calling the whole future of the effort into question over paperwork errors.
His answer to that question also clarified a few questions I've long held about corporate life:
"Oh, I know. Why do you think she is the Project Management Team Lead?"
"Does she know that is why she is the Team Lead? Because she is the preventer of progress?"
"No," he was smiling,"If it were intentional complication it would be considered sabotage. Her intent is pure, so everything is good."
It is possible, internet, to be promoted specifically for not getting things done and more for not getting things done in a spectacular manner while adhering to the letter of the corporate policy manual and ignoring its spirit.
While this fact brings a strange warmth to my heart, I suspect that is because 10+ years on the inside of this kind of place has left me a hollow shell of a person who delights in turning processes against themselves and each other in corporate policy gladiatorial death matches.
I also suspect that the standardization project has just gotten a resounding thumbs down from the crowd.