Let's make up an example. Let's say you have 2 processes, people have to: 1) check tests in with their code and 2) write their name on the whiteboard as the last person that checked code in.
Arguably process #2 might not be as useful. So people stop doing it consistently. Then it stops being done at all. New people come join the group and have to learn what processes are done, which ones are bent, and which ones are ignored. I think that this leads to a thought process of "well, if process #2 is optional, maybe #1 is as well". Ignoring one process is a broken window and will quickly lead to more being ignored.
If you have a process, there has to be some kind of audit or automated check. If there isn't, that means it has to really make sense why you are doing it so that it's not really a process, it's just "the way things are done". For processes without audits or 100% buy in, you have to question why you actually have it if it's not important enough to check that it is being followed.
I think that for all processes, every once and a while you should be asking yourself:
- does this process still make sense in our current env
- how much value does it bring
- how much does it cost
- could we be doing a different process for a greater ROI
If you have a process that is almost universally ignored, all that you are doing is weakening the other processes. It's a strange case where the whole is less than the sum of the parts. Back to our example, rather than having said anything about process #2, it's better to not have said anything at all rather than risk that people start to not check in tests with the code. But with that process, if there is no audit, no enforcement, that too will soon be an "optional" process. No matter how strong the process, there must be someone around to check for cracks starting before you have a flood on your hands.