SW 쪽은 잘 모르지만 일반적으로 이야기하면 처음에는 업무의 디테일을 제외한 프로세스만 이야기를 하십시오.
예를 들면 기획(or 수주)-개발-검수-배포-종료 절차의 만족(통과) 요건과 각 절차에서 생성되는 산출물의 종류만 이야기 하는 겁니다.
이 부분이 협의가 되면 각 산출물의 형식과 내용(포함되어야 할 것들)에 대해서 이야기 합니다.
산출물의 내용이 합의가 되면 해당 산출물을 생성하기 위한 업무 디테일에 대해서 이야기 할 수 있습니다.
이러한 프로세스의 개략적인 골격은 요즘은 AI 에게 정보를 충분히 주면 시안을 잘 만들어 줄 수 있을 것으로 생각되네요...

그리고 업무의 성격이 완전이 다르거나 SW의 종류가 서로 섞이지 않는다는 보장이 있다면 각 팀의 자율성을 보장하되 사람이 바뀌고 시간이 지나더라도 각 부서에서 통일성을 잃지 않도록 최소한의 규칙을 명문화 하여 제출해 달라고 요청합니다. (naming rule 이라든가 하는 규칙이 적어도 팀 단위로는 지켜지고 있어야 함) 그 규칙만 누군가 전사적으로 취합하여 관리하면 됩니다.
다만 이 경우에도 제일 위에서 이야기한 프로세스는 전사 표준을 따라야 합니다.

표준 프로세스의 결정은 bottom up 보다는 최고 경영자로부터 top down으로 내려가는 것이 효과적입니다. 일단 시안을 만들어 배포하고 만약 언제까지 개선안에 대한 피드백이 없으면 그대로 적용된다고 대표님이 나서서 푸시를 해야한다는 뜻이죠. 대표가 부서장들끼리 잘 협의해서 만들어 보세요~~ 하면 안되게 되어 있습니다.

miragefire님과 비슷한 이야기인데, 개발 업계에서 흔히 사용되는 개발 milestone이 있습니다.
DIA > PIA > DVR > PVR > PRA > SRA 정도인데, 각 단계가 무엇을 의미하는 지는 인터넷에 많이 있으므로 별도의 설명은 생략하고요, 이 프로세스의 각 단계별 milestone을 pass하는 criteria를 정의해야 합니다. 예를 들어 DIA (개발 투자 승인) 경우, 상품기획부서 발의, 개발팀 합의, 마케팅 합의, 재무부서 합의 및 경영자 결재 같은 식으로 착수하게 만들어야 합니다. 물론 miragefire님 말씀대로 단계별 산출물에 대한 표준 템플릿은 준비되어야 하구요. 각 단계 별 발의/결재/합의 라인은 마일스톤 중요도에 따라 다릅니다.
프로세스의 단계별 정의 만이라도 디테일하게 되어있으면 어느정도의 표준화는 된다고 보면 됩니다. 각 팀 내부에서 개발을 누워서 하던, 외주를 주던 간에요.

이 경우 좋은 방법은 방안을 먼저 제시하고 "언제까지" 합의안을 결정해라 못하면 제시된 방안으로 실시한다 하는 것입니다.