69. 프로젝트 스폰서 및 추진 위원회 감리

⚠️ 이 문서는 대규모 IT 프로젝트가 기술적 결함이 아니라 '부서 간의 이기주의'나 '경영진의 무관심' 때문에 산으로 가는 것을 막기 위해, 프로젝트에 예산을 대주는 최고 책임자(Sponsor)와 각 부서장들이 모인 최고 의사결정 기구(Steering Committee)가 제대로 작동하며 제때 의사 결정을 내려주고 있는지 평가하는 관리적 감리 항목을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 프로젝트는 개발팀 혼자 하는 것이 아니다. 영업팀과 회계팀이 서로 "이 화면에 우리 부서 로고를 더 크게 넣어!"라고 싸울 때, 이를 단칼에 정리해 줄 절대 권력자(경영진)의 개입 여부를 묻는 것이다.
  2. 가치: 감리인이 "추진 위원회가 한 달째 회의를 안 하고 있네요?"라고 지적하면, 실무자 선에서 핑퐁 치며 지연되던 악성 이슈(Scope Creep)들이 경영진 테이블로 강제로 끌어올려져 프로젝트 기간 지연을 극적으로 막아낸다.
  3. 기술 체계: 회의록(Meeting Minutes), 의사결정 지연 추적 대장(Issue Log), 에스컬레이션(Escalation, 상위 보고) 규칙 문서가 실제 프로젝트 현장에서 매뉴얼대로 굴러가고 있는지 문서와 인터뷰를 통해 깐깐하게 대조한다.

Ⅰ. 고아(Orphan) 프로젝트의 비극과 스폰서의 부재

개발자 100명을 갈아 넣어도 사장님이 관심 없으면 실패한다.

  1. 프로젝트 스폰서 (Project Sponsor):
    • 프로젝트의 예산을 쥐고 있는 임원(CIO, CFO 등)이다. 프로젝트가 성공하면 승진하고, 실패하면 잘리는 가장 절박한 사람이어야 한다.
    • 감리 포인트: 스폰서가 착수식(Kick-off) 때만 얼굴을 비치고 사라지지 않았는지, 월간 보고(Monthly Report)를 직접 받고 코멘트를 달아주는지 경영진의 관여도(Executive Involvement)를 평가한다.
  2. 사일로(Silo) 간의 갈등:
    • 차세대 ERP를 구축하는데, 인사팀은 기존 기능을 100% 똑같이 만들어달라 하고 IT팀은 클라우드 표준에 맞춰 빼자고 싸운다.
    • PM(프로젝트 매니저)은 이 둘을 중재할 힘(계급)이 없다. 결론이 안 난 채 개발 일정만 속절없이 흘러간다.

📢 섹션 요약 비유: 아무리 뛰어난 항해사(PM)와 선원(개발자)이 배를 몰아도, 선주(스폰서)가 목적지를 정해주지 않고 선실에 누워만 있으면 배는 폭풍우(부서 간 갈등) 속에서 빙빙 돌다가 침몰합니다. 감리인은 선주가 직접 조타실에 나와 선원들에게 명확한 지시를 내리고 있는지 매의 눈으로 감시하는 암행어사입니다.

Ⅱ. 추진 위원회 (Steering Committee)의 작동 원리

싸움을 말려줄 어른들의 테이블이 필요하다.

  1. 추진 위원회의 구성:
    • 스폰서(위원장)를 중심으로, IT 부서장, 영업 부서장, 재무 부서장 등 이해관계가 얽힌 모든 'C-레벨' 또는 '실장급' 임원들이 한 달에 한 번씩 모이는 최고 의결 기구다.
  2. 에스컬레이션 (Escalation) 정책:
    • 실무자 회의에서 3일 동안 합의가 안 된 이슈는 팀장 회의로 올리고, 팀장 선에서 1주일 내로 합의가 안 되면 **자동으로 추진 위원회 안건으로 강제 상정(Escalate)**되도록 룰이 정해져 있어야 한다.
  3. 감리인의 점검 지표 (회의록과 결단력):
    • 감리인은 추진 위원회 회의록을 열어본다. 단순히 "개발 잘 진행 중임"이라는 보고만 받고 밥 먹고 끝났다면 감리 지적 대상이다.
    • "A 부서와 B 부서의 결재 라인 통합 건에 대해, 스폰서가 B 부서의 양보를 지시하고 1억의 추가 예산을 즉각 승인함"과 같은 **피 튀기는 의사결정의 흔적(Action Item)**이 적혀있어야 정상이다.

📢 섹션 요약 비유: 추진 위원회는 회사의 대법원입니다. 동네 파출소(실무 회의)에서 해결되지 않는 층간 소음 분쟁(부서 간 요구사항 충돌)을 계속 방치하면 살인(프로젝트 실패)이 납니다. 따라서 일정 기한이 지나면 강제로 대법관(스폰서) 앞에 끌고 가 탕! 탕! 탕! 강제 판결(에스컬레이션)을 내리게 만드는 제도적 장치입니다.

Ⅲ. 의사결정 지연(Decision Latency)이 부르는 나비효과

결정을 안 내리는 것은 잘못된 결정을 내리는 것보다 프로젝트에 더 해롭다.

  1. 대기 시간 (Idle Time)의 낭비:
    • 화면 레이아웃에 대한 경영진의 최종 승인이 2주 지연되면, 기다리던 프론트엔드 개발자 10명은 2주 동안 아무 일도 못 하고 놀면서 인건비 수천만 원을 태우게 된다.
  2. 범위 기어오름 (Scope Creep) 현상 방지:
    • 결정을 미루는 사이 현업 부서에서는 "이왕 늦어진 거 이것도 추가해 주시고, 저것도 추가해 주세요"라며 요구사항이 무한정 부풀어 오르는 스코프 크립(Scope Creep) 현상이 발생한다.
    • 추진 위원회는 "예산이 없으니 그 추가 기능은 다음 2차 프로젝트 때 합시다"라고 냉정하게 쳐내는(Cut-off) 악역을 맡아야 한다.

📢 섹션 요약 비유: 식당에서 손님(현업)이 메뉴를 고르지 못하고 "이것도 먹고 싶고 저것도 먹고 싶은데 어떻게 하죠?"라며 30분째 고민하면 주방(개발팀)은 올스톱 됩니다. 이때 매니저(추진 위원회)가 나서서 "오늘은 손님 예산에 맞는 이 세트 메뉴로 하시죠!"라고 단호하게 결정해 줘야 주방에 불이 켜지고 요리가 시작되는 원리입니다.