'PM을 위한 핵심 노하우' IT 프로젝트 성공을 보장하는 16가지 단계

프로젝트 관리 업무에 통달하기란 쉽지 않다. 기본적으로 프로젝트 규모에 관계없이 '만만한' IT 프로젝트라는 것이 없다. 프로젝트 결과에 대한 큰 기대치와 시시각각 변화하는 요건, 상충되는 특성 등 프로젝트 관리자 앞에 펼쳐진 이러한 어려움을 돌파하고 프로젝트를 성공시키기 위해 필요한 것은 업무에 대한 숙련도가 아니다. 오히려 문제 해결을 위한 구체적인 지식과 경험을 능숙하게 조합하는 능력이 더 필요하다. 여기, 단순히 살아남기 위해서가 아니라 프로젝트 관리에 성공하기 위해 반드시 알아야 하는 내용을 필자의 책인 '베어본 프로젝트 관리'(Bare Bones Project Management)에서 발췌해 모아봤다.

 

지식 : 7x6의 법칙을 따르라

IT 프로젝트는 기간이 늘어나고 팀이 커질수록 실패할 가능성이 높아진다. 프로젝트가 너무 길어지면 긴장감이 사라진다. 또 팀이 너무 크면 팀 구성원들이 사람들 속에 숨어버리기 십상이다. 반면 프로젝트가 아무리 크더라도 7x6의 법칙을 어기지 않는 다수의 프로젝트로 쪼갤 수 있다. 7x6의 법칙이란 7명의 핵심 팀 구성원과 6개월 이하의 기간을 의미한다. 중요한 것은 이것이 단계가 아니라 프로젝트라는 것이다. 일반적으로 단계는 길어지면 다음 단계에서 추가로 시간을 벌충할 수 있을 것으로 생각하게 된다. 따라서 7x6 법칙에 따라 반드시 기한내 마쳐야 하는 프로젝트로 보고 관리해야 한다.

 

지식 : 경영진의 지원은 필수다

프로젝트가 성공하려면 고위 임원의 지원이 반드시 필요하다. 그렇지 않으면 여러 이유로 중단될 가능성이 높다. 반드시 필요하다고 생각되는 프로젝트를 시작할 생각이라면 당장 이를 지지해 줄 수 있는 임원부터 찾기 바란다. 인력 지원, 우선 순위, 팀원들의 자신감 등은 모두 궁극적으로 프로젝트 수행 여부를 결정할 수 있는 최고 의사결정권자 앞에서 프로젝트를 옹호하는 임원이 있어야만 가능하다.

 

경험 : SINO를 피하라

임원의 지원은 반드시 필요하지만 프로젝트가 진정으로 성공하려면 이름뿐인 후원자(Sponsor In Name Only) 이상이어야 한다. 프로젝트의 성공을 위해 필요한 임원은 다음과 같은 사람이다.

 

• 1. 남들을 대표해 위험을 부담할 만큼 개인적으로 프로젝트를 원하는 사람
• 2. 필요에 따라 시간과 예산, 인력을 지원할 수 있는 권한이 있는 사람
• 3. 프로젝트 종료 시기를 결정할 권한과 의지가 있는 사람

 

한 가지 더 있다. 이러한 임원은 관리감독하는 사람이 아니라 파트너이면 금상첨화다. 프로젝트 관리자는 감시가 아니라 지원이 필요하다. 프로젝트에 SINO가 아니라 실제적인 지원 임원이 없다면 당장 프로젝트를 중단하거나 책상 밑에 숨어 버리는 것이 좋다. 무엇을 하든 업무를 받아들이지 말라. 불길한 징조이기 때문이다.

 

지식 : 유형의 성과를 내야 한다는 것을 명심하라

프로젝트 관리자는 프로젝트의 작업물을 제 시간에 본래의 예산 범위 내에서 제공해야 할 책임이 있다. 그게 전부다. 여기서 '작업 결과물'이란 무엇인가? 이것은 프로젝트를 통해 생성된 유형의 것이다. 이것을 직접 가리키면서 "보이지? 저기 있잖아"라고 말할 수 없다면 작업 결과물이 아닌 것이다.

 

경험 : 점들을 연결해 핵심을 도출하라

프로젝트 관리자의 유일한 공식적인 책임은 프로젝트의 작업 결과물을 제공하는 것이지만 관련된 요소들을 연결해 프로젝트가 의도했던 핵심 가치를 도출할 수 없다면 이 책임을 맡지 않는 것이 좋다. 여러 요소들을 연결할 수 있다는 전제 하에 핵심적 가치를 실제로 실현할 수 있도록 모든 것을 해야 한다. 이것이 중요한 이유는 매우 명확하다. 만약 일이 계획한 대로 풀리지 않을 때 누가 책임을 지게 되는가? 바로 프로젝트 관리자다.

 

지식 : 모든 참여자가 헌신하도록 하라

교과서적인 명제지만 프로젝트 팀 구성원들은 프로젝트에 전담 배치되어 별다른 할 일이 없지 않는 한 프로젝트에 전념해야 한다. 사실 이것은 비결 같은 것도 아니다. 예를 들어 IT 서비스 기업들의 경우 계약에 따라 프로젝트에 완전히 몰입한다. 문제는 내부 IT 팀만으로 프로젝트를 진행하는 경우다. 프로젝트에 참여한 모든 사람들이 다른 업무도 병행하기 때문에 헌신하도록 하는 것이 쉽지 않다. 특히 단순히 프로젝트에 배치시켰다는 것만으로는 아무 것도 상황을 바꿀 수 없다는 것을 명심하라.

 

경험 : 헌신이 불가능하다면 집중을 강조하라

맞다. 현실적으로 헌신적인 직원이란 존재하지 않는다. 대신 자신의 업무시간 20%를 프로젝트에 사용하라는 지시를 받는 평범한 직원들이 있을 뿐이다. 그렇다면 방법이 없을까? 있다. 20%로 만족하지 말라. 사실 이것만으로는 절대로 불가능하다. 대신에 매주 목요일마다 이를 100%로 끌어올리라. 지금은 20%에 불과하지만 언젠가 목표치에 도달하게 될 것이다.

 

지식 : 업무를 계획하고 계획한 대로 처리하라

이 말은 오랜 격언이지만 오해하고 있는 사람들이 많다. 이 말은 계획이 일단 수립되면 돌판에 새겨져서 태양이 다 타버릴 때까지 절대로 바뀌지 않는다는 뜻이 아니다. 이 격언의 진정한 의미는 '훌륭한 프로젝트 관리자는 업무를 즉흥적으로 처리하지 않는다'는 것이다. 상황이 바뀌어 이전 계획이 더이상 의미가 없으면 계획을 수정해 새로운 상황에 맞춰야 한다. 그리고 새로운 계획에 따라 처리하면 된다.

 

경험 : 프로젝트에 필요한 것은 업무 할당이다

막대로 구성된 간트(Gantt) 차트에 대해 익히 알고 있을 것이다. 프로젝트를 성공적으로 완수하려면 간트 차트 같은 것을 이용해 각 업무를 언제 시작하고 끝낼 지 그리고 누가 책임질 것인가를 정한 목록이 있어야 한다. 물론 경영진과 의사 소통을 하려면 이 외에도 필요한 것이 많다. 하지만 프로젝트 팀은 이것만으로 충분하며 사실 이것이 프로젝트 수행에 있어서 가장 중요한 부분이다.

 

지식 : 프로젝트 종료 회의를 반드시 가져라

프로젝트의 끝을 공식 선언하는 종료 회의의 목적은 여러가지다. 가장 중요한 것은 "우리는 프로젝트를 진행 중이다"로부터 "진행되고 있는 프로젝트가 없다"를 구분하는 명확한 경계선을 제공한다는 것이다.

 

경험 : 배경이 성공을 부른다

프로젝트 관리자는 프로젝트를 지지하는 임원이 회사에 대해서는 물론 개인적으로도 프로젝트의 중요성에 대해 이야기할 때 그 배경에 대해 이야기할 수 있도록 해야 한다. 그리고 프로젝트 팀은 이에 귀를 기울여야 한다. 그래야 나중에 나중에 프로젝트가 옆길로 새고 다른 임원이 문제를 제기했을 때 그 임원이 조용히 입다물고 수수방관하지 않게 된다.

 

지식 : 매주 진행상황을 모니터링 하라

매주 팀 구성원에게 진행상황을 업데이트 받으면 적절한 균형을 유지할 수 있다. 사전에 문제를 파악하면 세세한 것까지 관리하지 않고도 문제를 해결할 수 있다.

 

경험 : 회의가 동기를 부여한다

프로젝트 진행상황에 관한 회의를 매주 진행하라. 업무가 지연된 팀 구성원들이 이메일을 통해서만 이를 알린다면 그저 그런 상황을 알게 되는 것으로 끝이다. 따라서 주간 회의를 통해 동료들과 얼굴을 맞댄 상태에서 업무를 제대로 처리하지 못했음을 공개적으로 이야기하라. 프로젝트 관리자가 일정에 따라 모든 것을 처리할 때 동료 집단의 압력은 매우 유용한 도구이다.

 

경험 : 90% 완성도 여전히 미완성이다

진정한 프로는 제 시간에 임무를 완수하지 못한 팀 구성원을 다루는 두가지 원칙을 알고 있다. 첫째 임무를 완수할 수도 있고 못할 수도 있다. 그러나 임무 별로 관리할 때 완수 비율은 의미가 없다. 둘째 임무를 완수하지 못했을 경우 다음을 반드시 확인해야 한다. "제 시간에 맞추기 위한 계획은 무엇인가?" 그렇다면 언제 이 질문을 던져야 할까? 팀원 모두가 모인 주간 회의에서 이런 질문을 통해 모두가 완수 일정이 지연된 경우 그에 대한 대비책이 있어야 한다는 것을 상기시켜라.

 

경험 : 개발 범위가 빈번하게 변경되지 않도록 방지하라

성공적인 개발 범위 관리의 핵심은 두가지다. 첫째 세상에 공짜는 없다. 프로젝트의 범위를 변경한다고 해서 문제가 되지는 않는다. 이를 추가하는 것을 합의하는 것이 어려운 것이다. 둘째 결정을 널리 알려라. 개발 범위를 정하는데 일일이 간섭할 필요가 없다. 프로젝트 관리자로서 해야 할 일은 개발 범위가 바뀌는 추가로 비용이 든다는 것을 분명히 하고 계획을 바꾸는 것이다. 물론 최종적으로 범위를 수정할 지 여부를 결정하는 것은 임원 또는 운영위원회다.

 

경험 : 프로젝트가 표류하는 일반적인 문제의 원인을 파악해 해결하라.

프로젝트가 표류하는 이유는 크게 다음 세가지다.

 

• 1. 완벽주의: 작업 결과물을 개선할 수 있는 방법은 언제나 있게 마련이다.
  해결책: 작업이 충분히 만족할만한 상태에 도달했는지 여부를 파악하는 방법을 모두가 알도록 한다.
• 2. 담당 임원이 안달이 났다: 적어도 담당 임원은 작업 결과물로 생산에 돌입하고 부서의 운영 방식을 변경할 시기가 올 때까지 안전하다.
  해결책: 특히 프로젝트가 마무리 단계에 접어들 때는 담당 임원을 안심시켜라.
• 3. 관성: 때로는 아무도 "이제 완성이다"라는 말을 할 줄 몰라 프로젝트가 표류하곤 한다.
  해결책: 공식적인 종료 회의를 만들라. 모두가 모인 자리에서 "이제 프로젝트는 끝났다"고 선언하라.

마지막으로 필요한 것 : 성공을 축하하라

소형 프로젝트는 고되다. 그리고 이 때문에 더 힘들어진다. 분명한 것은 쉬운 일은 없다는 것이다. 따라서 아무리 작은 프로젝트라도 성공하면 팀원 전체를 모아 놓고 (최소한) 피자 몇판 시켜 진심을 담아 수고했다고 마음을 전해야 한다.

 

---

'PM을 위한 핵심 노하우' IT 프로젝트 성공을 보장하는 16가지 단계