📋 완벽한 계획보다 중요한 것, 함께 계획하는 시간입니다

 

계획은 쓸모없어지지만, 계획하는 행위는 영원하다

프로젝트를 시작할 때 우리는 모두 완벽한 로드맵을 만들려고 노력하죠. 세심하게 일정을 짜고, 마일스톤을 설정하고, 리스크까지 미리 고려해서 문서화합니다. 그런데 이상하게도 그 계획대로 진행되는 프로젝트는 거의 없어요.

시장조사기관 PMI(Project Management Institute)의 2024년 보고서에 따르면, IT 프로젝트의 약 68%가 초기 계획 대비 일정이나 범위가 변경된다고 해요. 그렇다면 우리는 왜 계획을 세우는 걸까요?

저도 이전 직장에서 대규모 CRM 시스템 교체 프로젝트를 진행하면서 이 질문에 대한 답을 찾았어요. 놀랍게도, 프로젝트를 성공으로 이끈 건 '계획 문서' 자체가 아니었습니다. 바로 '함께 계획하는 과정'이었죠.

실패한 드롭다운, 성공한 CRM 전환의 차이

같은 회사, 같은 제품 안에서도 프로젝트 결과는 극명하게 달랐어요. 먼저 실패 사례부터 말씀드릴게요.

경영진이 더 나은 데이터 수집을 원해서, 고객 프로필에 드롭다운 필드 두 개를 추가하기로 했어요. 간단한 작업처럼 보였지만, 이게 무려 세 번의 고위 임원 회의와 수많은 사전 미팅의 주제가 됐죠. 어떤 옵션을 넣을지, 카테고리를 어떻게 나눌지, 용어를 어떻게 정할지 끊임없이 논의했어요.

결과는 참담했어요. 아무도 사용하지 않았거든요. 영업 팀은 추가 입력을 원하지 않았고, 수집된 데이터는 실행 가능하지도 않았어요. 우리는 왜 그렇게 많은 시간을 허비한 걸까요? 정작 중요한 질문은 하지 않았기 때문이에요.

반면 CRM 전환 프로젝트는 달랐어요. 노후된 오라클 CRM을 교체해야 했는데, 모든 변경사항에 여러 단계의 승인이 필요한 상황이었죠. 그래서 우리는 '계획 뒤의 계획'을 만들었어요. 단순히 개발 마일스톤만이 아니라, 조직 내에서 승인을 받고 신뢰를 구축하는 전략까지 포함한 계획이었죠.

실제 영업 사원들로 구성된 파일럿 그룹을 만들어서 실시간 피드백을 받았어요. 전면 도입 승인을 요청할 때쯤이면, 경영진은 이미 몇 달 동안 시스템이 잘 작동하는 걸 지켜본 상태였죠. 결과적으로 3개월 안에 지역별 출시가 완료됐고, 사용자 채택률도 높았습니다.

재미있는 건, 원래 계획은 계속 바뀌었다는 거예요. 기능 우선순위를 조정하고, 일정을 수정하고, 출시 순서도 바꿨어요. 그런데도 성공할 수 있었던 이유는 모두가 같은 멘탈 모델을 공유하고 있었기 때문이에요.

계획이 아니라 계획하기가 만드는 세 가지

McKinsey의 2023년 연구에 따르면, 성공적인 디지털 전환 프로젝트의 82%는 팀 간 명확한 커뮤니케이션과 공유된 이해를 핵심 성공 요인으로 꼽았다고 해요. 제 경험상 계획 과정이 만들어내는 것은 정확히 세 가지입니다.

첫째, 공유된 언어예요. CRM 프로젝트 팀은 "파일럿 테스팅 전략에서 논의한 것처럼"이라고만 말해도 모두가 즉시 이해했어요. 우리가 이미 고려한 트레이드오프가 뭔지 다들 알고 있었거든요. 새로운 이슈가 생겨도 공통의 맥락 위에서 빠르게 판단할 수 있었죠.

드롭다운 프로젝트는 달랐어요. 공유된 기반이 없었죠. 모든 회의가 처음부터 다시 시작이었고, 같은 논쟁을 반복했어요. 우리가 집단적으로 무엇을 달성하려는지 확립한 적이 없었으니까요.

둘째, 의사결정의 골격이에요. 좋은 계획은 가정을 명확하게 밝혀요. CRM 출시에서 우리는 계획이 지역 리더십의 조기 동의와 파일럿 그룹의 열정 유지에 달려 있다는 걸 알고 있었어요. 기술적 지연이 일정을 위협했을 때, 어떤 가정이 위험한지 정확히 알고 접근 방식을 조정할 수 있었죠.

드롭다운 프로젝트는 골격이 없었어요. 채택률이 떨어졌을 때, 왜 그런지 또는 무엇을 다르게 해야 할지 이해할 프레임워크가 없었죠. 그저 "왜 안 쓰는 거지?"라고 물을 뿐이었어요.

셋째, 어려운 대화를 위한 강제 기능이에요. 많은 분들이 이걸 과소평가하시더라구요. 계획 과정은 스프린트 중간에 해결할 시간이 없을 때가 아니라, 그 전에 갈등을 드러내요.

CRM 프로젝트는 너무 깊이 들어가기 전에 조직 정치, 사용자 저항, 기술적 제약에 대한 불편한 대화를 하도록 강제했어요. 드롭다운 프로젝트는 어려운 대화("영업 사원들이 정말 이걸 사용할까?")를 피하고, 대신 쉬운 대화("드롭다운 옵션은 뭐로 할까?")에 집중했죠.

변화를 전제로 한 계획 세우기

Gartner의 2024년 설문조사에 따르면, 프로덕트 리더의 74%가 분기별 우선순위 변경을 경험한다고 해요. 그렇다면 어떤 계획이 실제로 효과가 있을까요?

저는 이걸 "피봇을 위한 계획(Plan to Pivot)" 접근법이라고 불러요. 미래를 더 잘 예측하는 게 아니라, 미래가 불가피하게 놀라움을 안겨줄 때 빠르게 반응할 수 있는 기반을 구축하는 거죠.

가장 먼저 할 일은 가정을 명시적으로 밝히는 거예요. CRM 출시에서 우리는 계획이 작동하기 위해 참이어야 하는 것들을 적어뒀어요. 지역 리더들이 파일럿에서 가치를 봐야 하고, IT 보안이 오라클 구현을 승인해야 하고, 영업 사원들이 추가 업무가 아니라 테스팅 그룹에 참여해야 한다고요.

기술적 지연이 일정을 위협했을 때, 우리는 스케줄에 대해 패닉하지 않았어요. 대신 "이게 어떤 가정을 위협하는가?"라고 물었죠. 알고 보니 파일럿 그룹 열정(세 번째 가정)이 위험했고, 거기에 에너지를 집중했어요.

다음 월요일에 한번 해보세요. 현재 프로젝트를 가져와서 성공하기 위해 참이어야 하는 세 가지를 적어보세요. 희망 사항이 아니라 실제 의존성을요. 뭔가 변경될 때, 어떤 도미노가 넘어졌는지 알 수 있을 거예요.

마감일이 아니라 결정 시점을 설정하세요

드롭다운 프로젝트가 실패한 이유 중 하나는 마감일(분기 말까지 출시)은 있었지만 결정 시점(영업 사원들이 정말 원하는지 언제 검증할까?)이 없었기 때문이에요.

CRM 프로젝트는 재평가할 특정 순간들을 내장했어요. 첫 파일럿 그룹 피드백 후, 지역 리더십 검토 후, 초기 보안 감사 후. 이건 우리를 느리게 만든 게이트가 아니었어요. 우리의 가정이 여전히 유효한지 알려주는 체크포인트였죠.

"첫 50명의 사용자가 2주간 테스트한 후 재평가하겠습니다"는 "3분기까지 출시"보다 훨씬 가치 있어요. 하나는 정보를 주고, 다른 하나는 압박을 주거든요. 정보는 의사결정을 도와주지만, 압박은 그냥 스트레스만 줄 뿐이에요.

마라톤이 아니라 청크로 계획하세요

제 계획 접근법에서 가장 큰 변화는 모든 것에 같은 수준의 디테일이 필요하지 않다는 걸 깨달은 거였어요. 다음에 오를 언덕에는 구체성이 필요하고, 그 너머의 산맥에는 방향만 필요하죠.

CRM 출시에서 우리는 첫 파일럿 그룹을 상세하게 계획했어요. 어떤 부서? 어떤 지역? 피드백 메커니즘은? 그들의 의견을 어떻게 통합할까? 그 계획은 구체적이고 명확했죠.

하지만 전체 출시 계획은 의도적으로 모호하게 유지했어요. 다음에 갈 지역은 대략 알고 있었지만, 파일럿에서 배운 것을 기반으로 조정할 수 있도록 시퀀스를 고정하지 않았어요. 이게 바로 적응력이에요.

Harvard Business Review의 2024년 기사에 따르면, 애자일 방법론을 채택한 조직은 시장 변화에 3배 더 빠르게 대응한다고 해요. 모든 걸 똑같이 상세하게 계획하는 건 함정이에요. 통제의 착각을 만들면서 실제로는 적응력을 떨어뜨리거든요.

먼 미래를 너무 구체적으로 계획하면, 새로운 정보가 들어와도 기존 계획에 집착하게 돼요. "이미 다 계획했는데..."라는 생각 때문이죠. 하지만 계획을 청크로 나누면, 각 단계에서 배운 걸 다음 단계에 반영할 수 있어요.

결국 중요한 건 함께 고민한 시간

여러분의 계획은 틀릴 거예요. 시장은 변하고, 우선순위는 바뀌고, 그 분기 1차 기획에서 모두가 동의했던 기능은 4월쯤 되면 무의미하게 느껴질 거예요. 이건 비관주의가 아니라 그냥 프로덕트 작업의 현실이에요.

하지만 계획하는 과정은 팀이 빠르게 피봇할 수 있게 만들어요. 왜냐하면 이미 함께 어려운 질문들과 씨름했기 때문이죠. 드롭다운 프로젝트와 CRM 출시 모두 예상치 못한 도전에 직면했어요. 한 팀은 적응했고, 다른 팀은 더 많은 회의를 잡았죠.

계획은 여러분의 지도지만, 계획하기는 항해하는 법을 배우는 거예요. 지도는 구식이 되지만, 항해 기술은 남아요. 그리고 그게 바로 제품을 출시하는 팀과 드롭다운에 뭘 넣을지 논의하기 위해 세 번의 고위 임원 회의를 잡는 팀의 차이입니다.

저는 이제 완벽한 계획서를 만드는 것보다, 팀원들과 화이트보드 앞에서 보내는 두 시간을 더 신뢰해요. 그 시간 동안 우리가 공유하는 이해, 드러내는 가정, 나누는 대화가 어떤 문서보다 강력하거든요.

핵심 요약

완벽한 계획 문서를 만드는 데 집중하지 마세요. 대신 팀과 함께 계획하는 시간에 투자하세요. 그 과정에서 만들어지는 공유된 언어, 의사결정 골격, 그리고 어려운 대화의 경험이 실제로 여러분의 프로젝트를 성공으로 이끕니다. 가정을 명시하고, 결정 시점을 설정하고, 청크로 계획하세요. 계획은 바뀌지만, 함께 계획한 팀은 어떤 변화에도 대응할 수 있습니다. IT 프로젝트의 68%가 초기 계획을 변경한다는 통계가 말해주듯, 변화는 예외가 아니라 규칙이에요. 중요한 건 변화에 휘둘리지 않고 함께 항해할 수 있는 팀을 만드는 거예요.