들어가며 - 왜 프로젝트 일정은 항상 밀릴까?
프로젝트를 하다보면 일정대로 흘러가는 법은 거의 없습니다.
아무리 WBS를 상세하게 정해도 몇 주 ~ 길게는 몇 달 단위로 밀리는 것도 예사죠. 그 이유는 간단합니다. 프로젝트 구축 단계에서 체크리스트 없이 '감'으로 일정을 짜고, 프로젝트 설계를 하기 때문입니다.
이번 포스팅에서는 신규 프로젝트 구축 시, 반드시 사전 확인해야 되는 체크리스트를 정리해보겠습니다.
포스팅이 좀 길어질 듯 하여, 이번 포스팅에선 하드스킬적인 체크리스트는 제외하고 우선 기술 외적인 '소프트'스킬 관점에서 체크리스트를 먼저 포스팅하겠습니다.
제가 몸소 겪으며 체득하게 된(저도 체득하고 싶지 않았습니다...) 사항들입니다.
프로젝트의 시작 단계에서 정해야 할 것들
1. 목표 정의가 되었는가?
프로젝트의 시작은 '무엇을 만들지'가 아니라, '왜 만들어야 하는가'이다.
많은 PM/기획자들이 요구사항을 정리하면 프로젝트의 기초단계가 끝났다고 생각하지만, 요구사항은 어디까지나 프로젝트의 '목표'를 이루기 위한 방법입니다.
즉, 프로젝트를 하는 목적이 무엇인지, 어떤 문제를 해결할 것인지 선행되고나서 요구사항 정의를 하는 것이 순서입니다. 프로젝트를 공유하는 문서 가장 상단에 모두가 볼 수 있게 프로젝트의 목표를 명시해놓는 것이 좋습니다.
이렇게 하면, 요구사항 정의할 때나 프로젝트를 진행할 단계에서도 수시로 이 프로젝트의 목표가 무엇인지를 인지하며 진행할 수 있게 됩니다.
2. 결정과 승인 체계가 정해져있는가?
A : "이거 왜 이렇게 했어요?"
B : "C과장님이 이렇게 하라고 했는데요..."
A : "이 기능은 왜 이렇게 변경된거예요?", "누가 이렇게 하라고 한거예요?"
프로젝트를 하다보면 이런 상황을 자주 마주쳤을겁니다.
아주 작은 프로젝트라면 사실상 PM이 결정과 승인권자이지만, 규모가 다소 큰 프로젝트라면 모든 승인과 의사결정을 PM이나 IT기획자가 할 순 없습니다.
반드시 각 모듈 별로 승인과 의사결정 절차를 명확하게 정리하는게 좋습니다. 그래야 의사소통 문제가 발생하지 않습니다.
아래의 체크포인트를 고려해보시면 됩니다.
| 항목 | 체크포인트 |
|---|---|
| 승인권자 리스트 | 각 기능/모듈별 최종 승인자 명시 |
| 의사결정 프로세스 | 어떤 단계에서 누구의 승인이 필요한지 |
| 기록 보존 | 모든 사항은 로그, 문서화 하기 |
Jira와 같은 툴을 쓰면 애초에 프로젝트 설정 단계에서 각 Epic이나 task 별로 승인절차를 설정하는 것이 좋고, 별도 문서로 정리한다고 했을 때도 승인절차와 결정체계를 문서화 시켜놓고 공유 하는 것이 좋습니다.
3. 요구사항은 Freeze 되었는가?
아마 프로젝트가 지연되는 가장 큰 이유일 것입니다. 요구사항이 수시로 변경되고, 정말 심한 경우엔 아예 시스템 구조부터 바꿀 정도의 큰 요구사항 변경이 발생하는 경우도 있습니다.
그래서 반드시 요구사항 Scope Freeze를 정의해야 합니다 (반드시 해야 합니다... 우리의 정신건강을 위해서 반드시...!)
요구사항 Scope Freeze란 "이 프로젝트의 요구사항 범위는 여기까지입니다."라고 문서로 확정시켜놓는 것입니다. 하지만 업무담당자들은 보통 요구사항 Scope Freeze고 뭐고 "이 기능 안되면 안돼요. 무조건 되게 해주세요."라고 요청할 것 입니다.
이럴 땐 요구사항 Scope Freeze 문서를 근거로, 이후 변경된 요구사항에 대해서는 프로젝트가 아니라 변경요청으로 관리하겠다는 스탠스가 되어야 합니다.
"그래도 결국 요청하면 해줘야되는건 똑같은거 아니야?" 라고 생각할 수 있지만, 요구사항 Scope Freeze가 확정되면 생기는 이점은 다음과 같습니다.
- 프로젝트 본연의 기능을 먼저 진행하고 이후 변경요청을 후순위로 진행할 수 있는 근거가 마련된다.
- 초기 설정한 요구사항을 충실히 이행할 수 있어, 프로젝트 일정 차질에 문제 생기는 것은 방지한다.
- 현업담당자들이 요구사항을 더 면밀하게 고민하게 되어, 프로젝트 완성도가 올라간다.
"이 요구사항대로 프로젝트 진행하는 것을 동의했으니 이대로 진행합니다" 라는 것을 문서화 해놓는 것입니다.
4. 법적 / 사규 범위에서 문제 되는 부분은 없는가?
이 부분은 개발자출신, 혹은 Tech PM쪽으로 좀 더 치우친 분들이 많이 놓치는 부분입니다. 특정 프로젝트의 경우는 법적 리스크를 특히 더 고려해야 될 부분이 많을 수 있습니다.
예를 들어 금융권이 그렇습니다. 금융권은 개인정보보호, 망분리 정책, 전자금융거래법 등 법적인 리스크를 감수해야 될 부분이 많습니다.
"요구사항이 이러니까 기술적으로 이렇게 저렇게 설계하면 되겠다."
위와 같이 기술적으로만 고민하고, 프로젝트를 수행하다보면 정작 그 이전에 체크됐어야 할 법이나 규정에 대한 부분을 간과하게 되는 것입니다.
예를 들어 고객정보를 관리하는 금융시스템을 개발한다고 했을 때, 기술적으로는 전혀 문제 없이 구현이 되었는데
개인정보를 외부에서 접근할 수 있는 아키텍처로 설계가 되었다던가,
개인정보조회에 대한 승인절차, 혹은 데이터 관리에 대한 설계가 보안이 전혀 없이 시스템 구성이 되었다던가...
이렇게 되는 순간 그 시스템은 IT적인 관점에서 완성도가 높더라도 망한 프로젝트가 되는 것입니다.
💡 Tip. 요구사항을 분석할 때 기술적으로 가능한가를 생각하기 전에 "이 방식이 규정과 법적으로 허용되나?"를 먼저 생각하는 습관을 들이시면 좋습니다.
5. 커뮤니케이션 채널은 단일화 되어있는가?
"프로젝트 실패의 70%는 소통의 오해에서 생긴다"
위에서도 한번 언급했지만 프로젝트를 하다보면 서로 의사소통에 이슈로 요구사항이 엉뚱하게 도출된다던가 요구사항과 다르게 엉뚱하게 개발되는 경우가 많습니다.
이를 위해 반드시 커뮤니케이션은 단일화 된 채널에서 진행되어야 합니다. 물론 프로젝트 진행 시에는 개발팀, 디자인팀 등이 별도로 해당 분야에 대한 이슈관리와 소통을 위해 별도 서브채널을 만드는 것은 괜찮습니다.
하지만 프로젝트의 일정과 전체 마일스톤에 대한 공유는 반드시 하나의 채널에서 공유가 되어야 합니다. Jira, 슬랙, 팀즈, 엑셀, 구글독스 다 좋습니다. 중요한 것은 하나의 통일된 채널에서 프로젝트의 진행이 공유가 되어야 한다는 점입니다.
결국 중요한 것은 정보의 일관성을 지키는 것 입니다.
결론 - PM의 실력은 '감'이 아니라 '체계'를 구축하는데서 나온다.
프로젝트는 결국 하나의 작은 사회와 마찬가지입니다. 사람간의 합의, 결정, 소통을 통해 하나의 완성된 작품을 만드는 것이죠.
이 중 하나라도 정렬되지 않으면, 반드시 프로젝트는 흔들리게 되어있습니다.
위에서 살펴본 소프트적 프로젝트 관리 스킬은 사회로 치면, 사회의 규칙과 법을 제정하는 단계라고 보시면 됩니다. 규칙과 법이 있어야 비로소 그 사회가 정상적으로 돌아가는 것이죠.
✅ 한줄 정리 : 좋은 PM은 일정을 정하기 전에 '체계'를 먼저 만든다.
다음 포스팅에선 하드스킬 관점에서의 체크리스트를 살펴보겠습니다.
읽어주셔서 감사합니다.