I'm a fan, in general, of process improvement (PI) initiatives, particularly when they equate to defining and documenting primarily undefined processes. However, given that complexity is a threat to security, I get concerned when PI programs become so complicated that it's hard to understand what's going on. I also get concerned when groups independently define processes that are related or dependent, without the proper buy-in or collaboration.
As security professionals, we should be asking for PI, just as we ask for policies and data flows to be defined (you are asking for data flows, right?). However, given our cross-org perspective, we should also work to bring together complementary projects to help reduce complexity and duplication. The unique vantage point of infosec should provide these insights, leaving you with the value-add responsibilities and opportunities of identification and coordination.
That all being said (quite possibly poorly said), there are a couple triggers to watch for to identify PI issues:
1) Are there disparate initiatives underway? e.g. ITIL and ITSM and CMMi, etc.
2) How many documentation standards exist? e.g. are there 2 or more non-integrated standards, or none at all?
3) Do teams meet jointly, or only on their own? i.e. how collaborative are these programs?
4) Who's ultimately in charge? Do they know/realize this? Have they made sure to deconflict programs?
5) Is there resistance to any of the programs underway? If so, what's being done to deconflict?
If any of these triggers triggered :) for you, then it's probably time to find the/an owner in senior/executive management and raise the issue. When you do so, make sure to back up your assertions, and for bonus points, suggest a couple ways to solve the problem.
Remember: the objective is to reduce complexity. In this case, that reduction will come through deconflicting overlapping or contentious PI projects, clearly delineating roles and responsibilities, which should overall be aligned with security policies and best practices.
