[류한석의 피플웨어] 성공하는 프로젝트와 실패하는 프로젝트의 차이점

2012년 08월 21일 류한석

참담한 프로젝트를 경험한 적이 있으십니까? 여러분이 참여하고 있는(또는 참여했던) 프로젝트가 다음 항목 중에서 몇 개나 해당되는지 한번 체크해보세요.

  • 사람들이 언제나 죽도록 바쁜데도, 일정을 지키기 힘들다. (도대체 누가 이 따위 일정을 수립한 거지?)
  • 매일매일 긴급한 일들 투성이다. (여기가 무슨 병원 응급실(ER)이야?)
  • 업무의 우선 순위가 계속 변한다. (아마도 오늘 하라고 한 일을 내일은 하지 말라고 하겠지. 이런 변덕쟁이!)
  • 회의가 너무 많아 일할 시간이 부족하다. (오늘도 할 수 없이 낮에는 회의하고 밤에 일해야겠네)
  • 사람들의 표정이 어둡고 건강에 문제가 생기는 사람들이 늘어간다. (우리, 마치 도살장에 끌려온 소 같아)
[류한석의 피플웨어] 프로젝트 스폰서와 프로젝트 헌장

저는 사회생활 초기 위의 항목과 완벽히(?) 일치하는 프로젝트를 해본 적이 있습니다. 당시의 경험이 제게 트라우마가 된 것이 확실합니다. 인정합니다. 거의 20년 전 일임에도 불구하고 아직도 기억하고 있을 뿐만 아니라, 지금 이렇게 그걸 얘기하고 있다는 게 바로 그 증거입니다.

부디 여러분은 그런 경험이 없기를 바랍니다만, 아마도 시장 경쟁이 치열한 업계에 있으면서 다년 간의 사회 경력이 있으시다면 최소한 두세 개 정도는 경험해 보셨을 겁니다. 계속해서 잘못된 방향으로 진행되는 불행한 프로젝트는 도처에 널려 있습니다. 그렇지만 사실, 그것에 대한 책임이 한 사람에게만 있지는 않을 겁니다.

프로젝트 스폰서(Project Sponsor, 한 명이 아니라 그룹일 수도 있습니다), 프로젝트 관리자(역시 한 명이 아니라 관리팀일 수도 있습니다), 프로젝트 팀원, 고객/사용자(프로젝트의 결과물을 사용할 개인이나 조직), 수행조직(프로젝트 작업에 가장 직접적으로 참여하는 직원이 소속된 조직), 그 외 영향력을 행사하는 사람 등 프로젝트 이해관계자의 종류는 다양합니다. 그 중에서 오늘은 프로젝트 스폰서와 관련된 내용을 살펴보도록 하겠습니다.

프로젝트 스폰서(영화로 치면 제작자입니다)는 프로젝트를 발족한 사람이자 재정적인 지원을 하는 사람입니다. 또한 프로젝트 스폰서는 프로젝트 관리자를 선임합니다. 프로젝트 스폰서는 프로젝트의 예산, 일정, 범위 등을 정하고 프로젝트 관리자와 협의하는 사람이기도 합니다. (참고로, 프로젝트 스폰서는 글로벌 표준의 프로젝트 관리 용어입니다)

만일 프로젝트의 재정을 지원하는 사람과 프로젝트의 결과물을 사용할 사람이 같다면, 프로젝트 스폰서 = 고객이라고 볼 수 있습니다. 그런 경우도 있습니다만 언제나 그런 것은 아닙니다. 프로젝트 스폰서는 대개의 경우 프로젝트 작업을 직접 수행하는 사람은 아닙니다만(일반적으로 그렇다는 뜻이고 어떤 경우에는 프로젝트 관리팀에 소속되기도 합니다), 프로젝트 초반에 직접적으로 수행해야 하는 중요한 일이 두 가지 있습니다. 그 첫 번째가 바로 프로젝트의 진행을 책임지는 프로젝트 관리자(영화로 치면 감독입니다)를 선임하는 것이고, 두 번째는 프로젝트 헌장(Project Charter)을 공식적으로 발행하는 것입니다.

프로젝트 관리자의 중요성은 여러분도 익히 아시는 사항이니 부연 설명을 할 필요가 없을 거 같습니다. 하지만 프로젝트 헌장은 익숙하지 않으신 분이 있을 겁니다. 프로젝트 헌장은 프로젝트의 존재를 승인하고 조직의 자원을 프로젝트 활동에 투입할 수 있는 권한을 프로젝트 관리자에게 부여하는 공식적인 문서입니다.

프로젝트 헌장에는 일반적으로 다음과 같은 항목들이 포함되는데, 꼭 필요한 내용만을 간결하게 기술하는 것이 좋습니다. 한마디로 ‘헌장’스럽게 만들어야 합니다.

◇ 기본 항목

  • 프로젝트의 명칭
  • 프로젝트에 대한 소개
  • 프로젝트의 목표 및 결과물
  • 프로젝트의 범위: 무엇을 포함시키고 무엇을 포함시키지 않을 것인지 표기합니다.
  • 프로젝트의 가정(Assumptions): 기술, 비즈니스, 자원, 일정 등에 대한 가정을 표기합니다. 만일 프로젝트 작업을 하면서 가정이 틀렸다고 판단되면 계획을 변경해야 할 것입니다. 변경의 정당성을 입증하기 위해 중요한 항목입니다.
  • 프로젝트의 제약(Constraints): 일정, 예산, 자원, 기술 등 프로젝트 계획을 수립하기 전부터 존재하는 각종 제약을 표기합니다. 예를 들어, 회사의 기존 제품을 반드시 재사용해야 한다거나 또는 특정 신기술을 반드시 이용해야 하는 경우가 있을 수 있습니다.

◇ 고급 항목

  • 프로젝트의 주요 마일스톤(Milestones): 주요 일정과 중간 결과물들을 표기합니다.
  • 프로젝트 조직도: 프로젝트 팀과 이해관계자들과의 관계를 다이어그램으로 표기합니다.
  • 역할 및 책임: 프로젝트 팀과 이해관계자들의 역할과 책임을 표기합니다.

하지만 안타깝게도 국내에서 진행되는 프로젝트들을 보면 프로젝트 헌장이 아예 존재하지 않는 경우가 대부분입니다. 비슷한 문서가 있는 것처럼 보여도 가정, 제약 등과 같은 주된 항목들이 빠져 있곤 합니다. 그리고 문서의 내용도 내용이지만 모든 주요 이해관계자들의 승인을 받는 것이 중요합니다. 그래야 프로젝트 헌장으로서의 가치가 있는 것이죠.

백이면 백 사람 다 생각이 다릅니다. 상황이 좋을 때는 별 문제가 없어도, 상황이 나쁠 때는 온갖 사소하고 잡스런 것들이 다 문제가 되는 게 바로 프로젝트입니다. 프로젝트 헌장은 망망대해를 항해하는 프로젝트에 있어서 나침반과 같은 역할을 합니다. 배가 잘못된 방향으로 가지 않도록 해주는 것이죠.

noah, tell me again who's your project sponsor?

프로젝트 헌장은 프로젝트 계획서가 아닙니다. 상세한 프로젝트 계획서를 작성하기 이전에 아주 간략하게 작성하는 문서입니다. 말 그대로 헌장이니까요. 주된 내용을 다 담았다면 1~2쪽이라도 좋습니다. 형식은 그다지 중요하지 않습니다. 또한 위에서 소개한 항목 외에도 나중에 ‘문제가 발생할 소지’가 있는 내용이 있다면 포함시켜도 좋습니다.

프로젝트 헌장이 필요한 몇 가지 이유

프로젝트 헌장은 주요 이해관계자들이 모두 참석하는 프로젝트 킥오프(Kick off) 미팅에서 공식적으로 승인되는 것이 가장 좋습니다. 그래야 뒤늦게 이의를 제기하는 걸 막을 수 있습니다. 저는 이걸 ‘멘탈 동기화’ 작업이라고 표현합니다.

제 경험으로 볼 때 프로젝트 헌장은 정말 중요한 문서입니다. 많은 사람들이 프로젝트 초반의 시간을 경시하는 경향이 있습니다. 프로젝트 초반에 간과한 많은 것들이 프로젝트 후반에 사채 빚(그것도 고리대금)이 되어 괴롭힙니다. 그러므로 프로젝트 초반에 바운더리(경계선)을 명확히 해놓는 것이 후반에 대단한 문제 해결력을 발휘하는 것보다 훨씬 뛰어난 프로의 역량이라고 볼 수 있습니다.

프로젝트 헌장에서 목표와 결과물을 명확히 해놓지 않으면, 팀원들이 눈 앞의 작업에만 몰두한 나머지 프로젝트의 궁극적인 목표와 동떨어진 결과물을 만들어낼 수도 있습니다. 또한 이해관계자들이 자신의 성공과 프로젝트의 성공을 분리해 생각하고 행동할 가능성도 커집니다. 일명 ‘목표 분리’ 현상이죠.

어쩌면 구두 의사소통이나 회의, 또는 다른 문서들을 통해 프로젝트 헌장의 내용을 어떻게든 공유하고 있다고 생각할 수도 있을 겁니다. 죄송합니다만, 그런 낭만적인 생각이 프로젝트를 망치는 경우가 많습니다. 프로젝트는 수많은 약속들로 이루어져 있습니다. 그런데 이해관계자들 중 한 명이라도 약속을 다르게 해석하면, 약속이 지켜지기는 커녕 불만과 분란만 커질 겁니다. 그러니 ‘암묵적인 약속’을 ‘명백한 약속’으로 만드는 것이 중요하며, 프로젝트 헌장은 그것을 이뤄주는 (완벽한 도구는 아닐지라도) 아주 유용한 도구입니다.

프로는 대화로 의사결정을 하고 문서로 보존합니다. 그래야 시간이 흐른 후 서로 다르게 의사결정 내용을 해석하는 걸 막을 수 있습니다. 프로젝트 헌장은 대화가 보존하지 못하는 기억을 보존합니다.

실제로 저는 프로젝트 헌장을 제대로 활용한 적이 있습니다. 제가 모 대기업에서 근무할 때의 일입니다. 원래 담당하던 프로젝트 관리자가 해임돼 제가 프로젝트를 맡게 됐는데, 프로젝트의 문제점을 면밀히 살펴보니 가장 큰 문제가 바로 고객의 변덕이었습니다. 회의를 할 때마다 요구하는 결과물이 계속 변하더군요. 거기에다 그 프로젝트에는 프로젝트 헌장 비슷한 것도 없었습니다. 그래서 저는 프로젝트의 재착수를 선언하고(이전 것을 버리고 새로 시작해야 하는 상황이었습니다) 킥오프 미팅을 하면서 가장 최선의 결과물을 정의하고 프로젝트 헌장을 공식화했습니다(원래는 프로젝트 스폰서가 해야 하는 일이지만, 현실적으로 그게 어려운 상황에서는 프로젝트 관리자가 작성해 승인을 받는 것도 하나의 방법입니다). 그 후에도 물론 그 고객은 변덕을 종종 부렸지만 제가 언제나 다음과 같이 얘기하면 태도가 달라지곤 했습니다.

“그렇다면 프로젝트 헌장의 수정을 위해 모든 이해관계자들이 모이는 미팅을 소집할까요?”

그러면 그 고객은 입을 다물었습니다. 사실, 귀가 얇았던 그 고객은 여기저기에서 들은 얘기를 불안한 마음에 마구잡이로 요구한 것이었는데, 자기가 무슨 얘기를 하고 있는지 그리고 그것이 미치는 영향에 대해서는 전혀 알지 못했습니다. 그런 고객에 휘둘린다면 프로젝트의 결과는 뻔할 수 밖에 없습니다. 어쨌든 프로젝트 헌장을 방패 삼아 좋은 제품을 만들 수 있었고 프로젝트 종료 후 고객도 매우 만족해 했습니다.

이처럼 프로젝트 스폰서는 프로젝트의 재정을 지원할 뿐만 아니라, 프로젝트의 초반에 프로젝트 관리자를 선임하고 프로젝트 헌장을 발행하는 중요한 역할을 맡고 있습니다. 또한 프로젝트 스폰서는 그 누구보다도 프로젝트가 성공하기를 바라는 사람이자 프로젝트를 옹호하는 사람입니다. 프로젝트 진행 중에는 프로젝트 수준이 아닌 조직 수준에서 발생하는 문제 해결에 도움을 주거나 프로젝트 관리자를 위한 멘토링이나 코칭도 합니다. 그리고 프로젝트 종료 후에는 프로젝트의 결과물이 최대한 유용하게 쓰일 수 있도록 최선을 다합니다.

이미지

유능한 프로젝트 스폰서는 자신보다 더 유능한 프로젝트 관리자를 선임하고 프로젝트의 목표와 결과물을 명확히 정의하고 문제 해결을 지원하는 반면, 무능한 프로젝트 스폰서는 자신보다 더 무능한 프로젝트 관리자를 선임하고 프로젝트의 목표와 결과물을 명확히 정의하기는커녕 프로젝트의 표류를 방치합니다.

그러니 프로젝트 착수 시점에서 프로젝트의 성공 가능성이 궁금하다면 프로젝트 스폰서가 어떤 사람인지 면밀히 살펴보고 판단하십시오. 부디 유능한 프로젝트 스폰서를 만나시고, 또 그런 사람이 되시길 바랍니다.

* * *

제가 사회생활 20년 동안 만난 사람들 중에서 단연코 최고의 프로젝트 스폰서였던 P상무님께서 암투병을 하시다 지난 달에 돌아가셨습니다(관련 글). 이 글을 P상무님께 바치고 싶네요. 여러분, 항상 건강하세요.