하얀 캔버스

출장 컴퓨터 보안 컨설턴트의 일을 하면서 매주 프로젝트 관리자들을 만나게 되는데, 이들 프로젝트 관리자를 보면 실력이 천지차이다.

최고의 프로젝트 관리자들은 자신의 역할을 심각하게 받아들이는 공격적인 현역이라 말할 수 있다. 이들은 큰 문제가 터지도록 놔두지 않고 결정을 내리고 행동을 취한다. 팀원의 기술 수준을 미리 평가하고, 첫째 날부터 전체적인 프로젝트 위험을 산정하고, 공식 프로젝트 계획을 만들고, 마감날짜를 정하고 작업을 할당해 모든 팀원이 목표를 달성하도록 돕는다.

필자는 프로젝트 매니지먼트 인스티튜트(Project Management Institute)로부터 인증을 받는 것이 경력에 도움이 된다고 생각하긴 하지만, 공인 프로젝트 관리자는 아니다. 내 프로젝트 관리 지식과 감상은 대부분 프로젝트 참여자일 때의 역경으로부터 배운 것이지만 가끔 프로젝트 관리자로서 배운 것도 있다. 프로젝트 관리를 잘하려면 기술과 제대로 된 사고방식 모두가 필요하다.

여기 성공적인 프로젝트 관리를 위한 공통 요소들을 몇 가지 소개한다:

1. 아무리 작은 프로젝트라도 프로젝트 관리자가 필요하다
일주일 이상 걸리면서 한 명 이상이 참여하는 모든 프로젝트에는 담당 프로젝트 관리자가 있어야 한다. 작은 프로젝트일 때엔 종종 기술 담당자가 프로젝트 관리자 역할을 겸임하게 된다. 그러면 돈과 자원을 절약할 수 있지만 프로젝트의 결과가 수준 이하로 나오는 경우가 종종 생긴다.

2. 목표를 가지고 모든 회의를 시작하라
모두들 회의를 실제 업무에 방해가 되는 시간낭비로 생각해서 피하고 싶어한다. 회의에 들인 시간을 실제 프로젝트 작업 시간보다 훨씬 많이 쓰는 수많은 회사들을 컨설팅 해왔다. 아무것도 해결이 안 되는 것처럼 보이는 게 과장은 아니다.

전체 회의는 최대한 줄여야 한다. 모든 회의는 왜 회의를 하는 것인지? 회의의 예상 결과는 무엇인지? 등 명백한 목적을 가지고 시작해야 한다. 한 사람은 회의 내용과 중요 결정 사항, 발견 정보, 작업 할당, 실천 사항, 분쟁 요점 등을 기록해야 한다. 각각의 작업은 마감기한을 가지고 한 사람씩 책임을 지고 맡아야 하고 그에 따른 문서도 기록해야 한다.

작업을 할당 받은 모든 사람은 작업에 대한 스스로의 이해와 마감시한을 회의 마지막에 재확인해야 한다. 모든 회의의 막바지에는 ‘다른 질문이 없느냐’는 확인이 있어야 한다. 이 모든 것이 읽을 때는 단순해 보이지만 얼마나 많은 회의가 실제적인 작업이나 실천사항 없이 끝나는지 놀라울 정도다.

3. 문서, 문서, 문서
마지막 요점을 확대해 보자. 꼭 무엇이든 기록해둬야 한다. 많은 사람들이 오직 말로 하는 의사소통만이 “진짜”이고 대화에서 표현되는 의도가 이메일이나 기록물에 제대로 표현되지 않는데 아쉬워한다. 문제가 아닐 수 없다. 우리가 문서화되지 않은 것을 인용할 수는 없으니까 말이다.

공개 토론에 문제가 없더라도, 이해사항을 이메일, 메모, 위키, 사용 가능한 경우 내부 소셜 미디어로 확인하라. 말로 합의를 본 사항을 사람들의 기억 속에서 끄집어내면 얼마나 많은 차이가 있는지 놀랄 것이다. 조심스러운 문서화는 그런 상황을 위한 보험이다. 만약 누군가 잘못을 저지른 상황에서 자신의 책임이 아니라면 합의사항 이메일을 통해 보호받을 수 있을 것이다.

4. 기술자 회의가 최고다
반면 특정 과제를 위해서는 실제 얼굴을 보는 것이 최고다. 정신 없는 기술적 문제가 발생하면 필자는 각자 전문 분야를 가진 모든 관련 기술자들을 한 방에 모으는걸 선호한다. 한 분야의 전문가가 다른 분야 전문가의 문제를 얼마나 자주 집어낼 수 있는지 놀라울 정도다. 진공상태에서는 아무것도 하지 않는다. 완전히 이해하지 못한 구성 패널에서의 작은 체크표시가 성공과 실패의 차이를 만들 수 있다. 분명히 실제 대면 회의는 화상회의나 음성회의보다 낫다. 의심이 든다면 이 유튜브 비디오를 한번 보라.

5. 필요한 만큼 세부적으로 관리하라
이 분야는 프로젝트 관리자가 두드러질 수 있는 영역 중 하나다. 만약 팀원이 작업에서 뒤처질 경우 프로젝트 관리자가 더욱 관여해야 한다. 프로젝트 관리자는 항상 세부 관리를 좋아하지 않는다고 말한다. 이런 관여는 몇몇 팀원에게는 도움이 되지만 다른 팀원들은 격려와 지속적인 주의 환기, 그리고 초반부터 칭찬과 보조를 필요로 한다.

6. 완충 시간을 마련하라 
원래 일정과 마감 날짜대로 마무리되는 프로젝트는 거의 본 적이 없다. 이를 극복하는 유일한 방법은 실제 마감 날짜보다 더 이른 날짜를 팀에 알려주는 것이다. 마감일을 바꿔 가르쳐주는 방법에 대해 놀라는 사람들이 있겠지만, 이는 전체 팀원들이 진짜 마감시한을 확실히 지키게 만드는 필자가 아는 유일한 방법이다.

몇몇 프로젝트 관리자들은 가상의 마감시한을 설정하고 필수적인 진짜 마감 시한을 드러낸다. 그렇게 하지는 말라. 진짜 마감시한을 드러내는 순간 팀 모두가 그들의 마감시한을 뒤로 미뤄 실제로 진짜 마감시한을 못 지키게 될 것이다.

7. 가능한 최고의 선임 기술자를 두라
프로젝트는 팀 활동이다. 안타깝게도 필자가 만난 몇몇 고액 기술자들은 뛰어나지도 않았고, 그들의 말과 달리 단 하나의 프로젝트도 제대로 완료해 내지 못했다. 그들의 추천사항이나 실수는 그들이 실제보다 이론에 뛰어남을 드러낸다. 반대로 한 분야에 가장 경험이 많은 기술자들은 회의적이고 부정적인 경우가 많다. 그들은 고집불통이고 성공에 반대가 될 수도 있다.

실제로 있었던 일이다. 상당히 흔한 시나리오 상 제품 이행을 돕는 한 선임 컨설턴트는 자사 소프트웨어의 구동과 관련된 컴퓨터의 최소 70%가 첫째 날 고장 났고, “더 이상 해볼 수 있는 게 없었다”고 말해주었다. 그는 이를 자랑하고 있었다. 그는 그 고장이 여러 다양한 문제들 때문이었고, 자신이 추진하던 관리형 클라이언트가 제대로 설정되지 않아서일 때도 잦았다고 말했다. 가끔 고장의 원인은 네트워크에 있었고, 또 만료된 디지털 인증 때문이기도 했고, 이런 수많은 원인들은 “나와 관련이 없는 것”들이었다고 한다.

우선 이 컨설턴트가 프로젝트 도중에 고객과 필자에게 이 점을 인정한다는데 크게 놀랐다. 둘째로 고객이 그에게 거액을 지불하고 그 프로젝트 이행에 도움을 청한다는 사실도 믿기 힘들었다. 셋째로 직접적인 제어 범위 내에 문제가 있건 없건 언제나 할 수 있는 일이 있다는 것이다. 만약 노드 절반 이상이 고장 난 프로젝트를 이끄는 기술자라면, 어찌되었건 문제는 자신의 것이다! 책임자는 거대한 문제를 제대로 보고 이를 해결하기 위해 고장 원인, 이행 과정, 절차, 문서 등을 파악해야 한다. 어느 누구도 높은 고장율을 당연시 해서는 안 된다.

좋은 관리의 효과
나이를 먹어갈수록 어느 무엇도 혼자 해낼 수 없다는 걸 깨닫는다. 필자는 컴퓨터와 네트워크 보호 방법을 알고 있다. 하지만 여기에는 수주에서 수 개월 동안 이어지는 기업 전반의 프로젝트 과정에서 이뤄지는 작업에 대한 기술 전문성 그 이상이 필요하다. 기술 외에도 좋은 프로젝트 관리가 필요하다. 이를 관철시켜라.