프로젝트 관리는 무엇입니까??????

오랜만의 글이다...

요새 조금 바쁘기도 했고, 그리고 얼마 전 출장도 다녀오고 ...

암튼 적조한 건 사실이고, 그리고 그 대부분은 나의 게으름이 만든 일일게다....

각설하고 ....

 

지난 주와 그리고 또 몇 주전 하루짜리이기는 하지만 출장을 다녀왔다.....

흠, 프로젝트 관리에 대한 이야기를 하러, 발표도 하고 그리고 고객사의 의견을 듣기도 하고 ...

 

우선 고객사의 의견 또는 이야기부터 ....

고객사는 이미 프로젝트 관리 시스템을 보유하고 있었다...

그것도 대충 관리하는 것이 아닌 요새 프로젝트 관리 시스템이 이야기하고 있는 거의 대부분의 영역을 가지고 있었다...

 

한시간 정도에 걸쳐서 고객사의 시스템 활용과 그 데이터 구성에 대한 설명을 들었다...

그리고 받은 느낌은 무언가 굉장히 많이 노력을 했다는 것과 그리고 아마 설명한 시스템에 대하여 한 10%정도만이 활용이 되고 있을 거라는 느낌 ... 그리고 정확한 통계는 아니겠지만, 고객사 역시 어느 정도는 공감을 했다......

 

그리고 앞으로 프로젝트 관리를 지속적으로 할 수 있을까??? 하는 물음이었다.... 물론 보유하고 있는 시스템을 활용하여 가능하냐는 이야기 였다.... 어차피 나도 장사하는 집단에 속해 있느지라, 당연히 우리 툴을 도입하는 것이 좋다고 말하고 싶었지만 .... 그렇게까지 이야기를 못했다..... 왜냐하면, 앞서 말했듯이 그런데로 잘 구성이 되어 있었기 때문이다.....

 

그래서 문제를 단점을 지적했다. 한 1시간 정도의 시간 동안 대화를 했다. 아마도 대화가 맞을 거다. 일방적인 서로의 의견을 이야기 한 것이 아니니까 ......

 

그럼 프로젝트 관리는 무엇인가????

 

PMBOK의 정의에 따르면,

"한시적인 기간 동안 지정된 제품 또는 서비스를 생산하는 것이며, 그 결과물은 고유한 또는 유일한 것이어야 한다."

위에 이야기가 PMBOK에서 내리는 간략한 정의이다......

 

결국 사고 싶지만 그러한 물건이 없기 때문에 사람과 물자, 비용을 투자하여 내 입맛에 맞는 그리고 내가 원하는 것을 생산하는 행위이다.

그래서 결국 유일한(unique) 것이 생산이 된다는 것이다....

 

그리고 그 결과물을 지속적으로 발전시키면, 다른 시장에 내다팔 수 있는 제품이 되는 것이다.......

간단하다.... 하지만 그 제약 사항, 그리고 그 검증과 결과물의 품질 때문에 관리 체계가 필요하게 되는 것이다.....

 

제약 1. 사람이 수행한다.

제약 2. 한정된 시간과 자원을 활용한다.

제약 3. 유일한 것이기 때문에 검증이 어렵다.

 

위에 언급한 세 가지 제약이 있기 때문에 프로젝트 관리 기법 또는 방법론, 관리 체계 등 다양한 형태의 관리가 발생하는 것이다.....

 

결국 업무 수행의 원활함 때문에 관리 도구를 도입하면, 통제가 어려워 지기 때문에 결과물의 품질 보장이 어려우며, 중간에 발생하는 이슈와 리스크의 통제가 제대로 지켜지기 어렵다. 그렇다고 결과물 때문에 통제에 촛점을 맞추게 된다면, 업무를 수행하는 사람의 입장에서는 프로젝트 업무 이외에 불필요한 업무량이 발생하기 때문에 한정된 자원과 시간을 지킬 수 없게 된다.....

 

아마 이게 가장 주요한 딜레마일 것 같다............

 

해결 방법이 있는가??? 있다... 적절하게 조화롭게 사용하는 것이다. 아주 주관적이지만, 이렇게 답변을 하는 것이 최선이다.

왜냐면, 결국 그 조직에 맞게 변화하고 변경해서 프로젝트 관리 도구를 사용해야 하니까 .......

 

그럼 보다 객관화 시켜 보자... 그런 것들이 프로젝트 관리 도구들이 해야 할 일이니까......

 

1. 정보 유통의 통로를 구조화 하기.

2. 해야할 일과 그렇지 않은 일을 구분하기.

3. 보다 세분화하고 전문화한 영역으로 나누기.

4. 세분화하고 전문화된 영역으로 나누어진 부분을 통합하기.

5. 품질을 지키기 위해서 반드시 지켜야 할 일을 만들기.

 

 

 

1. 정보 유통의 통로를 구조화 하기.

정보 유통의 통로라 함은 누군가는 정보를 입력하고, 그리고 누군가는 그 정보를 집계하고 통계를 만들고, 요약해야 하며, 또 누군가는 그 정보를 활용하고, 그리고 누군가는 그 정보 기반의 의사결정을 해야 함을 의미한다......

 

결국 만들어진 정보를 활용하여 의사소통을 해야 한다.

그러면 여기서 하나의 기준이 생긴다....

 

정보를 생산하는 사람. - 업무 담당자, 이슈나 위험 등록자, 각종 데이터 등록 및 자신의 상태 또는 현황을 업데이트 하는 사람.

정보를 유통하는 사람. - PM, QA, PMO 등 생산된 정보를 통하여 집계하고, 요약하고, 활용하고, 업무에 대한 지침을 관리하는 사람.

정보를 소비하는 사람. - PM, 임원, 품질, 프로젝트 검수자, 생산된 그리고 유통된 정보를 기반으로 의사결정을 하는 사람.

 

그리고 이들이 접속하는 기능 또는 메뉴 또는 관리 도구를 다변화하고, 그 정보의 최종 집계나 유통은 단일화 시켜야 한다.

산재된 정보를 위해서 여러 가지 메뉴나 화면에 접속하는 것이 아니라, 하나의 화면, 하나의 메뉴에서 조회할 수 있어야 한다.

 

이것이 정보 유통의 통로 구조화이다....

정보를 생산하는 채널을 다변화함으로써 정보 생산자는 보다 편하게 정보를 생산하고, 다변화된 채널을 통하여 집계하는 곳을 집중시켜 정보 유통자들의 업무 경감과 보다 편한 정보 유통 통로를 만들고, 결국 의사결정 체계 또는 화면, 메뉴, 시스템에 집중하여 의사결정을 위한 최소한의 정보 접속 채널을 단일화하고, 상세 정보는 그 하위로 상세화(drill-down)하는 그런 구조가 필요하다.

 

이것이 가시화이다.

화려한 챠트와 보고서가 아니라 정보의 관리 또는 조회, 활용 체계의 단일화 ......

 

물론 모든 정보를 하나의 메뉴에서 또는 하나의 화면에서 다 소화할 수는 없지만, 그 경로는 최소화하고, 그리고 사람이 인지할 수 있는 구성을 갖추어야 한다....

 

 

2. 해야할 일과 그렇지 않은 일을 구분하기.

이것은 생각보다 단순하다....

내가 접속할 수 있는 기능이나 메뉴만큼이 내가 할 일이며, 반드시 내가 하지 않아도 되는 일은 보다 하위에 구성시키고 메뉴를 단순화하는 것.....

그렇게 되면 내가 해야 할 일이 명확해 진다....

 

다만 내가 해서는 안되는 일의 제약이 어렵다...

가령 프로젝트의 업무 진척 보고를 허위로 한다던가??? 하지 않은 일을 이미 종료된 일로 바꾼다던가... 하는 행위를 막아야 한다.

여기서 통제가 발생한다........

그러면 어떻게 처리하는 것이 좋을까????

 

100% 허위 보고나 해서는 한되는 행위를 방지할 수는 없을 것이다.....

다만 막을 수 있는 방법은 과거 이력 정보의 비교, 타인과의 비교를 할 수 있는 구조를 만들어야 한다.

 

똑같은 분석 작업과 요구사항 정의서 작업을 진행하는 사람 중 어떤 사람은 8시간만에 끝내고 어떤 사람은 24시간이 걸린다면,

산술적으로 2일의 차이가 발생한다.

이 원인을 알 수 있어야 한다.

그렇지 않으면 허위 보고, 누락 보고 등을 방지할 수 없다.

 

 

3. 보다 세분화하고 전문화한 영역으로 나누기.

이 항목은 위의 두 가지 항목에 대한 통합 개념으로 봐도 될 것 같다.

어쨎거나 프로젝트를 관리하기 위해서는 여러 가지 영역이 필요하며, 그 영역에 대한 전문성과 다양성 그리고 집중된 관리 체계를 가지고 있어야 한다.

그래야만 업무의 중복성과 불필요한 업무 가중을 막을 수 있다.

QA에게는 모든 현황 또는 진행 정보의 집계과 요약의 권한을 주며, 그것을 활용하고 보고할 수 있으면 된다. 그리고 그 의견을 받는 보고 대상자는 판단을 해야 하며, 업무 담당자들은 업무를 진행하며 생기는 이슈를 등록하면 된다.

결국 프로젝트의 관리 체계를 세분화할 필요가 있는 것이다.

PM이 업무를 배정하고 업무를 집계하고, 위험을 처리하고, 사업을 관리하고, 검수를 하는 것이 아니라 정해진 규칙에 따라서 업무를 배정하고 보고를 받으면 되고, 배정된 업무의 모니터링은 개인과 그리고 QA 또는 PMO 등이 나누어 하면 되는 것이다.

 

이슈/리스크 처리의 해결 담당자가 그것을 검수할 수는 없는 노릇이지 않은가.......

 

 

4. 세분화하고 전문화된 영역으로 나누어진 부분을 통합하기.

그래서 통합이 필요하다....

나누어진 세분화된 전문 영역에 대한 업무 조율자가 필요한 것이다.

이렇게 배정된 인력은 자신의 업무에 대한 70%는 개인 업무 해결에 그리고 나머지 30%는 업무 조율에 배분해야 한다.

전문적인 프로젝트 관리일 수록 세분화된 관리 영역과 통합 조율자가 필요하다..

 

 

5. 품질을 지키기 위해서 반드시 지켜야 할 일을 만들기.

굳이 표현을 하지 않아도 당연히 지켜야 할 항목이다.

그러나 이 항목을 강제화하지 않으면, 품질에 대한 위험도가 상승하게 마련이다.

 

그래서 프로세스를 통한 업무 처리를 진행하고, 그 프로세스 중간 중간에 감사를 할 수 있는 요소가 필요하게 된다.

프로세스를 귀찮은 일이기도 하지만, 그 프로세스에 따라서 업무를 처리하면 최소한의 품질이 보장된다는 장점을 가지고 있다.

 

내 옆자리에 앉은 PM에게 구두보고 하지 않고, 굳이 프로세스를 태우는 것은 그러한 품질의 보장이며,

다른 한편으로는 내 책임에 대한 면책도 가능한 부분이 된다.

 

 

오늘은 이만 ....

===========================================================================================================================