I've seen that there seems to be two different views of what "process" means, I'll refer to them as the "pro" and the "con":
Con - Red tape, bureaucracy, and damaging politics - something that exists so that ivory-tower-folk can feel important. Examples include: wasting hours to reformat a private word doc so it meets "standards", or manually going through all your (perfectly functional, production) code to switch the naming convention from Pascal to Camel case.
I've seen projects where someone, with good intentions insists that "we need to improve our process", while others, also with good intentions, just cringe. The problem is that even though they're using the same words, they still mean different things. Obviously any good project should avoid the bad and emphasize the good.
With this, I offer several criteria that a good process should meet:
As a complete package, it should make life simpler. It should solve a specific problem that the team agrees needs solving. (run your tests, manage your source control, etc...)
It must always functionally work, from end-to-end. Process that produces bad output will just cause you bigger problems. It is better to have a slower process that works, then a faster process that randomly fails.
It should have public results so that everyone can see what happened
It should be publically documented, such as on a team wiki, so that others can understand it (as opposed to always bugging you for questions)
It should be easy to maintain (automated [perhaps with MSBuild], machine-independent, abstract out variables like pathNames to a config, etc...)
It should be easy to setup. Process that is a pain to install (perhaps requiring third party components that you don't have licenses for) will eventually just be ignored.
There's probably more criteria, but a process that fulfills all these is off to a very good start.