목록PM Story (40)
Joypia
PM이 가장 먼저 신경쓰는 것이 팀원 구성이다. 그리고 그 구성된 팀원을 어떻게 잘 이끌어 가는가가 프로젝트의 성패를 좌우한다. 팀원이 구성되는 경우는 대게 3가지 경우이다. - PM의 의사와 상관없이 팀원이 구성되는 경우, - 어느 정도 자기가 원하는 팀원으로 구성되는 경우, - 팀원의 일부 또는 전부가 계약직(프리랜서)으로 구성되는 경우 이다. 두번째를 제외하고 첫번째와 세번째는 PM 입장에서 여간 난감한 게 아니다. 우선 쉬운 두번째의 경우를 보자, 이런 경우는 보통 회사 사정이 여유가 있을 때 발생한다. 사업을 준비하는 단계부터 PM 으로 내정되고, 자기와 소통이 잘되고 실력 있는 팀원을 물색하여 해당 팀원의 동의도 받아 놓을 정도로 준비과정 부터 탄탄하다. 여기엔 PM의 리더로써 자질만 있으면 ..
자 그럼 일정 계획을 세워보자. 가장 힘든 작업이다. 단순 패키지를 커스텀마이징하는 것과는 달리 미래예측이기 때문이다. 가장 큰 이유는 그 주체가 '사람'이기 때문이다. 그래도 계획은 세워져야 한다. 그나마 다음과 같은 경우는 근미래(?)를 예측할 수 있다. 따라서 아래와 같은 사업을 계획했는데 큰 변경이 일어난다면 그 PM은 혼나야 한다. 1) 연차사업으로 해당 업무를 개발한 경험이 있는 경우 2) 타 기관에서 동일한 사업을 수행한 경험이 있는 경우 3) 이미 개발된 시스템을 재개발하는 경우 사실 위 1)번 사업을 제외하고는 2), 3) 번도 나름 리스크가 존재한다. 그래도 처음으로 개발되는 사업에 비하면 그 정도가 매우 낮다. 더 쉽게 설명하자면 경험이 중요하다는 것이다. 이 부분에 대한 모순을 해결..
PM 의 가장 큰 역할은 사업관리이다. 사업관리의 기본은 사실 매우 간단하다. 각 타스크 별로 일정 계획을 세우고, 그 계획대로 진행되는 지 점검하고 계획대로 안되었다면 따져본 후 적절한 후속 조치를 취해 지연 일정을 만회하면 되는 것이다. 말은 쉽다. 하지만 실현하기는 쉽지 않다. 우선 일정계획이다. 보통 WBS 방식을 사용한다. 이 계획이 잘 못 되면 모든 게 틀어진다. 두번째로 점검이다. 사실 PM 들의 가장 큰 문제가 점검을 할 줄 모른다는 것이다. 마지막으로 적절한 후속조치인데, 이 부분에서 PM 의 경륜과 노하우가 빛이나는 부분이다. 앞의 두가지가 부실해도 - 죽, 뒤 늦게 발견되어 사고가 터져도 마무리의 기술로 충분히 보완되기 때문이다. 각 항목에 대해 자세한 부분은 추후 시간이 되면 따져 ..
PM은 물론이고 개발자 모두가 반드시 몸에 베어야 하는 것들이 몇가지 있다. 그 중에 하나가 회의록 작성이다. 고객이나 이해 당사자가 모여 얘기를 하면 무조건 회의록을 작성하는 버릇을 들여야 한다. 이를 지키기 위해서는 PM 자신이 버릇이 들여있어야 함은 물론이고, 팀원들에게 뿌리 내릴 때까지 끊임없이 잔소리를 해야한다. 이렇게 하기 위한 몇가지 요령을 살펴보자. 우선 하나의 팀으로 구성된 프로젝트 조직이면, 팀원 중 회의록 작성 전담자를 지명하는 것이다. 회의록 전담자는 다음과 같은 사람을 고른다. 팀이 여러 개이면 각 팀마다 회의록 작성자를 임명해야 한다. - 신입 개발자는 피하는 게 좋다. 뜻도 모르고 적는 것에 정확한 기록을 기대하기 힘들기 때문이다. 따라서 적어도 3년차 이상 개발자에서 선택한다..
잘 알다시피 SI 는 맞춤복이다. 기성복과는 구매자의 요구가 사뭇 다르다. 아, 이 비유는 잘 못되었다. SI는 매우 큰 저택을 짓는 대공사다. 특히 설계와 공법은 최신 트렌드를 따르고 설비는 온갖 첨단 기술이 들어가는, 그런 저택을 짓는 것이다. 아파트에 들어가서 사는 것과는 사뭇 다르다. 이 표현이 어울린다. 해서 집주인(고객)은 저택이 완성되어 갈수록 욕심이 생긴다. 이는 처음엔 집에 대해 잘 모르다가, 시간이 지나면서 조금 이해를 하게되고 어떤 것이 가능한 지 느낌이 오기 때문이다. 따라서 만족감이 오히려 완료단계에 와서 떨어질 수가 있다. 비유를 든 것이니 SI 프로젝트에서도 마찬가지라는 이야기다. 이런 갈등이 PM의 스트레스 지수를 높이고 수행사의 자원 추가와 일정 지연을 초래한다. 이에 대한..
많은 SI 회사들이 민수와 관수 또는 공공과 사기업으로 구분 짓는데는 상당한 일리가 있다. 특징이 뚜렷이 구분된다고 생각하기 때문이다. 고객, 이른바 '갑'이 나타내는 특징은 사실 공공분야가 일반기업 분야도 포함하고 있다고 생각한다. 즉 공공 특징의 일부만 사기업이 갖고 있다고 보는 견해다. 왜냐하면 나의 경우 7 대 3 정도로 공공과 일반을 경험했지만 사기업에서만의 별다른 특징을 찾지 못했다. 모든 분야가 그렇겠지만 이 분야의 일도 경험(여기서 경험은 갑을 대하는 경험을 말한다)이 쌓일수록 베테랑이 되어가고 그만큼 미래예측이나 대처 능력이 높아진다.이는 갑의 사고방식, 행동, 일처리 순서 등에 대한 일반적인 특징을 갖고 있기 때문이다. 우리는 그것 중에 아주 심한 경우를 "갑질"이라고 표현한다. 자 공..
PM 이 사업관리 하는 것 중에 가장 모호한 것이 위험과 이슈다. 도대체 이것의 기준이 무엇인가 헷갈리기 일쑤다. 지금까지 만나본 수 많은 감리들 조차 이 두가지를 구분하는 감리인을 만나보지 못했다. 그래서 어떤 경우에는 각각 관리 대장을 따로 만드는 것이 아니라 아예 '위험/이슈 관리 대장'이라고 하나로 작성하는 경우도 있다. 나는 이것을 이렇게 이해하고 있다. 물론 나 나름의 생각이라 정답이라고 할 수 는 없다. 위험은 프로젝트가 시작되기 전에 이미 식별된 것들이다. 이슈는 사전에 인지되지 못한 즉 프로젝트 수행 도중에 예상치 못한 리스크가 발생한 경우를 말한다. 문제는 이 얘기를 하려는 것이 아니라 앞서 얘기한 위험 관리에 대해 말하고자 한다. 내 생각에 따르면 위험은 미리 예견된 리스크라고 했다...
CHAOS Report 2015 자료를 보면 조금 흥미로운 내용이 있다. 5년 전이나 지금이나 프로젝트 성공율이 비슷하 것도 놀랍기는 하지만 이것 보다는 관심이 가는 3가지 통계치가 있다. 우선 프로젝트 규모별 성공율이다. 표에서 보면 규모가 클수록 성공율이 굉장히 낮아짐을 알 수 있다. 내 경험이나 언듯 생각해 보면 작은 프로젝트든 큰 프로젝트든 성공율에 큰 차이가 없어야 한다. 큰 프로젝트 일수록 공통팀이나 PMO 등 부가적인 조직과 지원이 많이 붙기 때문에 프로젝트의 품질도 그만큼 올라간다고 생각했다. 수치를 보고 가만히 생각하니 조금은 착각을 했다는 걸 깨달았다. 2~3 년 전부터 공공기관 정보시스템의 차세대 프로젝트가 시작되고 있다. 작게는 300억대에서 크게는 2,000억대 규모이다. 들리는 ..
5. 이음새를 넣자 공공SI 제안설명은 여러 가지 개별적인 단위 과제가 사업범위로 되어 있는 것이 대부분이어서 설명을 하다 보면 자칫 하나하나 끊어지기 싶다. 왜 그런지 일반적인 PT 순서를 살펴보자. - (프롤로그) : 제안에 앞서 - 제안 개요 : 제안배경 및 목적, 제안범위 등 - 제안 전략 : 사업성공요소, VOC, 제안 전략 등 - 사업수행 방안 : 각 개발 내용 또는 단위 과제 설명 - 사업지원 방안 : 조직, 방법론, 일정, 지원 사항 등 - (에필로그) : 제안을 마치며 요즘 트렌드 중에 하나는 위순서 중 전략 부분에 대해 세부 실행전략이나 ActionItem 내용으로 '사업수행방안'을 풀어가는 방법을 많이 쓰고 있다. 다른 분야의 PT는 한 가지 주제를 갖고 소위 "기.승.전.결"로 풀어..
공공 SI 에서 PT가 중요한 편에 속한다고 본다. 하늘을 봐야 별을 보듯이 수주를 해야 프로젝트를 할 수 있는 것 아닌가. 수주에는 반드시 제안설명 즉, PT 가 들어간다. 언제부터인가 PT를 그 프로젝에 예정된 PM 이 해야 한다는 조건이 붙어 PM 고민거리 중 하나가 되었다. 이 지랄 같은 조건이 붙은 것은 프로젝을 책임지고 수행할 PM 이 그 사업에 대해 설명할 수 있어야 되는 것 아니냐는 언뜻 들으면 그럴싸한 논리 때문인 것으로 알고 있다. 그 전엔 아무나 - 사업부장이나 PT를 그래도 좀 한다고 하는 사람이 했었다. 사실 PT를 잘한다고 반드시 프로젝 수행을 잘하리라는 보장은 없는 것이다. 하지만 현실은 그렇지 않으니 어떡하겠는가. 대부분 PM 이 PT를 잘 못하는 이유는 아주 가끔 하기 때문..