'프로젝트관리론'에 해당되는 글 34건

  1. 2012.01.19 투자 수익률 분석 IRR과 NPV
  2. 2012.01.16 CAGR (연평균 성장률)에 대한 정리
  3. 2012.01.03 기획자에게 힘을 실어주자~ (2)
  4. 2011.12.22 제대로 된 모바일 어플리케이션 개발을 위해 필요한 역할들~ (1)
  5. 2011.10.04 FP(Function Point, 기능점수) 작성 방법에 대하여~ (2)
  6. 2009.01.04 PSA의 원칙과 실천단계
  7. 2008.09.29 프로젝트 팀원 역할 어떻게 설정해야 할까요?
  8. 2008.09.15 프로젝트의 성공 요인 분석 #2
  9. 2008.09.15 프로젝트의 성공 요인 분석 #1
  10. 2008.09.08 위험관리(Risk Management) 프로세스 #2

투자 수익률 분석 IRR과 NPV

|



IRR과 NPV라는 용어를 듣고 복잡한 공식을 보니 가슴이 답답해지네요. ^^
그래서 관련 자료를 찾아보다가 NPV, IRR이 왜 필요한지 실제 사례를 통해서 잘 정리된 블로그가 있어서 옮겨 봅니다.

http://blog.naver.com/zic235?Redirect=Log&logNo=90116509748

파란감자 님이 정리해 놓은 자료인데요.
이 글을 보니 조금은 이해가 됩니다. 나중에 참고할 수 있도록 해당 자료를 옮겨봅니다.

--------------
일반적으로, 기업에서 프로젝트 예산을 배정하고 진행여부를 검토할 때, 가장 기본적으로 쓰이는 방법이 IRR을 이용한 계산방법입니다. 이 IRR 값은 프로젝트를 수행하기 위해 필요한 최소의 수익률을 의미하며, 이 수익률이 프로젝트 예산 조달 비용(WACC이라고 하며, 추후 설명)보다 크면 프로젝트 진행을 할 수 있고, 작으면 해당 프로젝트는 “수익성 없음”으로 결론이 날 수 있습니다.
 
IRR 은 Internal Rate of Return의 약자이며, 영어로 된 의미가 좀 더 분명한 정의를 전달 할 수 있을 것 같아 아래에 적어봅니다.
 
“The IRR is defined as the discount rate that equates the present value of a project’s expected cash inflows to the present value of the project’s cost” 라고 정의되고 있습니다.
 
즉, IRR의 의미는 프로젝트에 소요되는 비용과 프로젝트로 인해 미래에 발생할 수익을 동일하게 만드는 Discount rate 라는 의미로써, IRR 은 NPV(Net Present Value) 값을 “0”으로 만드는 값이라고 할 수 있습니다.
 
NPV(Net Present Value)는 아래 표에 나타나 있듯이, 프로젝트 투자로 인해 매년 발생하는 이익을 현재가치 기준으로 조정한 값을 의미합니다. 이자율 10%을 기준으로 프로젝트 투자 1년 후에 들어오게 되는 $500의 수익은 현재 가치로 환산할 때 $454.55로 되며, 4년 후에 들어오게 되는 수익까지 모두 현재 가치로 환산해서 얻은 NPV 값은 $78.82 로서 투자 적합 판정을 받을 수 있는 기준임을 의미합니다.


표 1. 첫해 $1000을 투자한 후, 매년(~4년까지) 투자수익을 얻는 경우
 


 
NPV 값은 위와 같이 등비수열을 이용한 공식에서 얻을 수 있습니다.
 
NPV > 0 이면, 프로젝트 비용을 초과할만큼 Cash flow을 생성한다는 의미이고,
NPV = 0 이면, 프로젝트 비용을 커버할만한 Cash flow을 생성한다는 의미이고.
NPV < 0 이면, 프로젝트는 프로젝트 비용을 커버할만한 Cash flow을 생성하지 못
한다는 의미이므로, 이 프로젝트는 진행해서는 안 된다는 것을 의미합니다.
 
IRR은 NPV를 “0”으로 만드는 Discount rate 이므로, 아래와 같이 표현됩니다.
 


 
다시 말해서, IRR은 프로젝트 수행 여부를 결정하기 위한 가장 기본적인 수익률을 의미하며, 이 수익률이 자본비용 (WACC, Weighted Average of Cost of Capital)보다 높게 나와야, 즉 IRR > WACC 이어야만, 프로젝트 “Go”를 외칠 수 있는 것입니다.
 
그렇다면, WACC이란 무엇인지 또 궁금해 하실텐데, WACC이란 기업에서 자본을 조달하기 위해 필요한 비용을 의미합니다. 예를 들면, 기업이 시장에서 자본을 조달하기 위해 주식을 발행하면, 연말에 배당금을 지불해야 하고, 은행에서 Loan을 쓰면 이자를 지불해야 하는데, 배당금이나 이자가 모두 자본비용 항목에 속합니다.
 
즉, 해당 프로젝트에 드는 투자금액을 조달하기 위해 필요로 하는 추가 비용 (배당금, 이자 등, WACC)이 프로젝트의 수익률(IRR)보다 크다면, 다시 말해서 IRR < WACC 이라면 프로젝트를 진행해서는 안되며, IRR > WACC 이어야만 프로젝트 진행 허가를 받을 수 있다는 의미입니다.
 
자 이제, 그렇다면 위 개념을 이용해 모 프로젝트의 초기 예산을 알아내었던 방법에 대해 설명드리겠습니다.
 
해당 프로젝트로 인해 절감되는 인건비는 12명이며, 1인당 인건비는 4400만원으로 파악되었습니다. 프로젝트 투자 회수 기간은 8년이므로 아래 표와 같이 요약될 수 있습니다.
 
이 경우 IRR을 구하는 것이 목표가 아니라, 거꾸로 NPV(초기 투자비)를 계산하는 것이 목표인 점도 기억하십시요.
 
일반적으로, 모든 프로젝트의 투자비용에 대한 기업의 자본비용(WACC)을 구하는 것이 어렵기 때문에, IRR 값은 회사 내부의 경험과 수치에 의해 결정되는 것이 일반적입니다. 은행 이자율 / 배당금 정책을 고려해서 IRR을 10%로 고려해서 NPV를 구하면 아래와 같은 금액이 나옵니다. 즉, 초기 투자비용을 28억 정도로 생각할 수 있다는 의미입니다. 매년 5억2천8백만원은 “1인당 연간비용 4400만원 x 12명”으로 계산된 값입니다.
 
프로젝트 예산을 추정할 때, IRR과 NPV를 이용한 방식으로 유추를 하였으며, A 프로젝트, B 프로젝트에 예산을 각각 50%씩 배당을 했다는 정보에 기인하여, 프로젝트 예산 14억을 추정했고, 초기견적 13.6억을 제시하게 되었습니다.
 


표 2. 프로젝트 예산 추정 

좋은 자료 올려주신 파란감자님께 감사드리고 잘 활용하도록 할께요~~
새해 복 많이 받으세요 ^^

'프로젝트관리론 > 기획' 카테고리의 다른 글

투자 수익률 분석 IRR과 NPV  (0) 2012.01.19
CAGR (연평균 성장률)에 대한 정리  (0) 2012.01.16



Trackback 0 And Comment 0

CAGR (연평균 성장률)에 대한 정리

|



사업계획을 하다보면 여러가지 나오는 용어들이 있습니다. 
하나씩 시간 될때마다 정리해 보려고 합니다. 

오늘은 CAGR(compounded annual growth rate) 인데요.
글자 그대로 해석하면 연평균 복합 성장률 이라고 해야 할 것 같은데요. 
보통 연평균 성장률이라고 이야기 합니다. 

CAGR은 해당 기간(년도)의 성장률을 평균으로 환산한 것인데요.
매년 성장률을 단순 평균으로 계산한 것이 아니고 '첫해부터 매년 일정한 성장률을 유지한다고 했을 때의 성장률"을 의미합니다. 
수학적으로는 기하 평균의 원리를 이용한다고 하네요. 

예를 들어서 살펴보도록 하지요. 

2007년 100억
2008년 150억 (50.0%)
2009년 250억 (66.7%)
2010년 400억 (60.0%)
2011년 450억 (12.5%)
2012년 500억 (11.1%)

괄호 안은 전년 대비 성장률이라고 볼 수 있습니다. 
이것을 산술평균으로 내 보면 40.1%가 나옵니다. 

그러나 CAGR 값을 계산해 보면 38.0%가 나오게 됩니다. 
즉, 2007년부터 매년 38%씩 성장하면 2012년에 500억이 되는 것이죠. 

그럼 CAGR 값을 계산하는 공식을 정리하도록 하겠습니다. 
CAGR = (C/C0)(1/t)-1

Ct는 마지막 년도의 값, C0는 최초 년도의 값, t는 전체기간이 됩니다. 
위 예제에 값을 대입해서 살펴보면 다음과 같이 계산됩니다. 
CAGR = (500억 /100억)(1/5)-1 = 38.0%

위 계산 공식을 알고 있으면 쉽게 CAGR을 계산할 수 있을 것 같네요. ^^
엑셀에서는 XIRR이라는 함수를 별도로 제공하기도 합니다. 

만약 공식으로 사용하려면 제곱근을 ^로 쓰면 되니까 다음과 같이 사용하셔도 되겠네요. 
(500억/100억)^(1/5)-1



더 알아보기

투자 수익률 분석 IRR과 NPV

프로젝트 예산 배정 및 수행 검토를 위한 IRR과 NPV에 대해 살펴보세요.

기능점수(FP, Function Point)

프로젝트 견적시 사용하는 기능점수에 대한 내용입니다. 


사업 계획의 효율적 관리 린 캔버스

1장의 사업계획서 린 캔버스로 효과적인 사업 계획을 해 보세요.

린 캔버스의 모델이 된 나인 블락스

비즈니스 모델 설계를 위한 nine blocks에 대해서 살펴보시면 좋을 듯 합니다.

기획안 작성 요령

기획안을 만들 때 참고할 수 있는 내용입니다.



'프로젝트관리론 > 기획' 카테고리의 다른 글

투자 수익률 분석 IRR과 NPV  (0) 2012.01.19
CAGR (연평균 성장률)에 대한 정리  (0) 2012.01.16



Trackback 0 And Comment 0

기획자에게 힘을 실어주자~

|



새해가 밝았습니다. 
올 한해는 모두 소망하는 것들이 이루어지기를 바라겠습니다.

작년의 프로젝트를 정리하고 올 한해의 계획을 세우면서 다시 한번 느낀점이 바로 기획의 부재였습니다.
단순히 이런 아이디어가 좋다라는 것으로 시작해서 개발을 하다 보면
예상하지 못한 이슈들에 부딪히고 결국 흐지부지 되어 버리고 말죠.

누구의 말처럼 새로운 사업을 하는데 있어서 가장 흔한 것이 바로 아이디어가 아닌가 합니다. 
사람들은 자신의 아이디어가 아주 훌륭한 것처럼 이야기 하지만 결국 누구나 다 생각하고 있는 것이 바로 이 아이디어가 아닐런지요?
이런 아이디어를 구체화 하고 실현 가능하도록 만드는 것이 더욱 중요한 부분이라고 봅니다.

그런 측면에서 작년에는 기획이라는 부분의 필요성을 확실히 느꼈습니다. 
현재 기획자들이 경험이 없어서.. 외부의 훌륭한 기획자가 오면 프로젝트가 훨씬 나아지지 않을까 하고 생각도 했습니다.


그런데..
다음 글을 읽으면서 제가 뭔가 근본적인 것부터 잘못 생각하고 있다는 것을 깨달았습니다. 

기획자가 인정하는 기획자 무용론 (http://fredism.com/?p=1129) 

대규모 기업에서는 기획자에게 모든 프로젝트를 총괄하는 Priority가 있다는 겁니다.
그러나 스타트업이나 소규모 기업에서는 기획자에게 이런 권한을 주지 못한다는 것이죠.

생각해 보니 기획자가 첫째로 막히는 부분은 개발자와의 의사소통에 있다고 봅니다. 
저희와 같은 작은 규모의 기업은 개발자가 나이나 경험 등의 측면에서 기획자보다는 상위에 있습니다.
그리고 개발자는 전통적으로 수동적인 입장을 취하는 경우가 많지요.

그러다 보니 기획자가 자신이 생각한 바를 설명하기보다는 개발자의 의견을 듣고 개발이 어렵다고 하면 기획을 수정하게 됩니다.

둘째로 위 글에서처럼 모두 같이 회의하기 때문에 기획자가 만드는 기획안이나 화면구성안이 없어도 프로젝트를 진행하는데 문제가 없고 
또 대표님이나 이사님과 같은 윗분들과의 대화로 이슈를 해결하면서 기획자는 그저 문서나 만드는 작업으로 전략해 버리지 않았나 싶습니다. 

이런 환경이라면 뛰어난 기획자가 온다해도 제 역할을 수행하지 못하고
내부에서는 뛰어난 기획자라면서 별로인데.. 라는 이야기만 듣게 될 확률이 높을 것 같습니다.

올해 성공적인 프로젝트를 위해 기획자의 위상부터 재정립 해봐야겠습니다.
기획, 디자인, 개발, 테스트, 운영, 마케팅에 이르는 전 부분이 어느 하나 중요하지 않은 부분이 없겠지만, 
맨 앞에 있는 기획 부분 부터 차근차근 만들어보려고 합니다.

 





Trackback 1 And Comment 2
  1. GOODgle 2012.01.03 11:18 address edit & del reply

    좋은 글~ ^^

    • 미니~ 2012.01.03 15:17 신고 address edit & del

      GOODgle님 페북에서 저 링크의 글을 보고 쓴 거네요.. ^^
      새해 복 많이 받으시고, 올해 대박 나세요 ~

제대로 된 모바일 어플리케이션 개발을 위해 필요한 역할들~

|



모바일 시장이 발전하면서 개인도 모바일 App을 만들어서 돈을 벌 수 있게 되었습니다.
그러나 제대로 된 서비스를 만들려면 어떠한 역할들이 필요할 지 한번 정리해 봤습니다. 

1. 기획 (Planning)

- 새로운 서비스/시스템을 기획
- 일반적인 아이디어를 보다 실현 가능하도록 구체화 함 
- 서비스 기획안, 화면 구성 방안 및 사용자 매뉴얼 등을 작성 
 독서량이 많아야 한다. (다양한 분야의 도서를 읽어야 함)
 기존의 서비스를 많이 사용해 봐야 한다.
 기획하려는 분야의 전문가가 되어야 한다. 
 좋은 아이디어를 선별할 수 있는 판단력이 있어야 한다.
 기획하는 서비스에 대한 시장 조사 능력이 있어야 한다.
 
2. 디자인 (Design)

- 디자인은 단순히 그림을 그리는 것이 아님
- 디자인은 해당 서비스의 이미지를 구축함으로써 성공 여부를 결정함
- UI/UX에 대한 디자인을 수행 (사용자 경험 중시)
 Best Practice와 같은 좋은 디자인을 많이 봐야 한다.
 개발자가 아닌 사용자를 고려하여 서비스를 디자인 해야 한다.
 다양한 입력 방식과 같은 새로운 사용자의 경험을 반영해야 한다.
 매번 새로운 디자인 스타일을 구축해야 한다. 
 웹과 모바일은 디자인에 있어 화면의 크기를 고려해야 한다. 
 
3. 설계 (Architecture)

- IT 서비스를 위해서 개발보다 중요한 것이 설계임 (잘못된 설계는 추후 엄청난 손실을 가져옴)
- 보통 설계자는 개발자보다 많은 경험을 가지고 있음
- DB 설계, Framework 설계, 기능 설계 등을 수행함
 플랫폼(DB, 프로그래밍 언어, 시스템)에 대한 상세한 분석이 필요하다.
 새로운 기술의 등장과 함께 누구보다 먼저 연구해야 한다.
 서비스의 효율을 결정하는 분야이므로 성능 개선에 항상 관심을 가져야 한다.
 DB / OS / 네트워크 / 프레임워크 등 각 분야별로 전문가가 되어야 한다.

 4. 개발 (Development)


- 실제로 서비스나 시스템을 위한 프로그램을 개발하는 분야임
- 프로그래밍 환경은 끊임없이 변화하고 있으므로 빠른 대응이 필요함
- 서비스 가능한 프로그램을 개발함

 프로그램 개발을 위한 기술을 습득해야 한다. 
 개발 관련 기술은 끊임없이 변하므로 꾸준히 학습해야 한다. 
 기존의 API를 최대한 활용하여 개발의 생산성을 높여야 한다. 
 과거 수행한 개발 내역을 자산화 하여 유사한 프로그래밍에 재사용 해야 한다.
 
5. 테스트 (Test)

- 현대의 IT 환경에서 테스트의 중요성이 점차 강화되고 있는 분야임
- 테스트는 정상적인 상황 뿐만 아니라 비정상적 환경에서도 수행해야 함
- Black Box 테스트, 경계 테스트, 예외 처리 테스트 등을 수행함
 테스터는 상당한 끈기와 노력을 요구하는 분야이다. 
 테스트의 중요성에 비해 다른 분야보다 대우를 받지 못하기도 한다.
 테스트 시나리오를 작성하고 이에 따라 철저하게 테스트를 수행해야 한다.
 테스트에서 찾지 못한 오류를 서비스 개시 후 발생하게 되면 손실이 크다. 

6. 운영 (Operating)

- 서비스의 지속적인 발전을 위해서 운영 업무를 수행해야 함.
- IT 분야에서 운영은 하드웨어와 같은 시스템 모니터링 및 장애 대응과 같은 것을 포함함.
- VOC 운영, 시스템 운영, 유지 보수 운영 등의 업무를 수행함

 하드웨어 시스템에 대한 많은 지식을 가지고 있어야 한다.
 시스템 모니터링, 장애 대응, 네트워크 모니터링을 위한 기술들을 습득해야 한다.
 개발을 지원하기 위한 서버 구성 등도 수행해야 한다. 
 고객 대응의 경우, IT 분야는 아니지만 서비스 운영에서는 필요하다.  
 




Trackback 0 And Comment 1
  1. 미니~ 2011.12.22 13:01 신고 address edit & del reply

    금주에 고등학교에서 직업 관련 강의가 있었습니다.
    소방관, 경찰관, 스튜어디스, 보디빌더까지 각 직종의 30여분이 오셔서 학생들에게 각자 강의를 했는데요.
    제가 IT 관련 직종을 설명하면서 이야기한 내용입니다. ^^
    회사 관련 소개 하구 IT 프로젝트가 개발이 전부는 아니다 라는 관점에서 여러가지 이야기들을 해 주었네요~

FP(Function Point, 기능점수) 작성 방법에 대하여~

|



프로젝트를 수행할 때 규모산정은 꽤 중요한 비중을 차지하고 있습니다. 
프로젝트의 관리를 위한 초기 예측으로 활용되기도 하지만 보다 현실적으로는 프로젝트 비용을 결정하기 위해서 많이 사용이 됩니다. 

프로젝트의 규모 산정은 다음 그림과 같은 방식으로 할 수 있습니다. 

 
주로 소규모의 프로젝트에서는 간단하게 투입인력수 방식인 M/M로 계산을 많이 합니다.
그리고 예전에는 코드 라인수로 계산하는 LOC (Line Of Code) 기법도 종종 사용했지만..
최근에는 대부분 기능점수라 하는 Function Point를 주로 사용하고 있는 현실입니다.

가끔 주변에서 Function Point로 견적을 내달라는 요청을 받기도 합니다.
여기 저기 자료를 찾아봐도 너무 어려운 표현으로만 되어 있어 FP는 일단 어렵다는 느낌을 받는 것 같습니다.
그래서 보다 쉽게 FP(기능점수)의 작성방법에 대해서 설명해 보려고 합니다.

FP (Function Point, 기능점수)란? 
소프트웨어가 가지는 기능의 개수를 기준으로, 그 소프트웨어의 규모를 측정하는 수법이다. 소프트웨어의 개발비용 등을 산정하는 데에 이용된다. 1979년에 IBM사의 A.J.Albrecht이 고안한 방식이다.
FP법이 개발되기 전에는 소프트웨어의 소스코드의 행수(SLOC; Source Line of Code)나 파일크기 등이 소프트웨어 규모의 척도로서 이용되어 왔다. FP법의 등장하고 나서는 보다 객관적이고 정량적인 소프트웨어의 규모를 산출할 수 있게 되었다.
FP의 산출에는, 소프트웨어 내에서 어떠한 처리를 하고 있는지를 추출하고 입출력 등 기능마다 분류하여, 각각을 [펑션](기능)이라고 정의한다.
펑션 마다 레코드 종류의 개수, 데이터 항목의 개수로 부터 펑션의 [복잡함]을 정의하고, 개별 펑션의 평가치를 산출한다.
평가치의 어플리케이션 전체의 합계가 [미조정 펑션포인트]이며, 거기에 소프트웨어의 영향도(상하 35%)를 곱하면 [조정이 끝난 펑션포인트]가 산출된다.
FP법의 보급을 꾀하기 위해 1986년에 국제단체 IFPUG(International Function Point Users Group)이 발족되었다. ISO에서 FP법의 표준화 작업이 진행되고 있다.


FP (기능점수)를 작성해 보자!!


FP를 작성하기 위해서는 여러가지 사항을 고려해야 합니다. 
먼저 아래 정보통신산업진흥원에서 나온 그림을 보시죠~


FP를 위해서 고려해야하는 항목입니다.
여기에서 복잡도 가중치, 또 다음에 고려해야 할 보정계수에 대해서는 일단 고려하지 않으셔도 됩니다.

왜냐하면 FP를 요구하는 대부분의 업체에서 해당 포맷과 적용 데이터를 가지고 있기 때문입니다.
엑셀로 작성된 FP에 여러분들은 기능항목과, 위에 있는 기본적인 데이터를 넣으면 FP 값은 계산되어서 나오게 됩니다.

그러므로 제가 관심을 가지는 부분은 다음과 같습니다.

1) 기능레벨을 추출한다.

FP를 작성하기 위해서 가장 중요한 항목은 FP를 적용할 기능항목들을 추출하는 것입니다.
보통 3단계 레벨로 구성하고 각각의 기능설명을 상세하게 기록합니다. 

2) 내부논리파일(ILF)와 외부연계파일(EIF)를 구분한다. 

대부분의 프로젝트에서는 DB 또는 외부 연동을 진행하게 됩니다. 
그러므로 이러한 항목을 ILF나 EIF로 구분해서 판단해야 합니다. 

개발하고자 하는 시스템에 저장되는 DB나 파일의 경우에는 ILF로 계산하고, 
외부에서 연동을 통해 가져오거나 업데이트 해야하는 항목에 대해서는 EIF로 계산하면 됩니다. 

3) 외부입력(EI), 외부출력(EO), 외부조회(EQ)를 작성한다.

먼저 외부입력(EI)를 살펴보면 보통 이야기하는 CRUD에서 C(create), U(update), D(delete)를 생각하면 쉽습니다. 
즉, 각각의 기능에 대한 입력, 수정, 삭제가 일어나는 회수를 계산해서 적어주시면 됩니다. 

이어서 외부출력(EO)과 외부조회(EQ)를 잘 구분하셔야 합니다. 
외부출력(EO)이라 함은 데이터를 읽어와서 특정 프로세스를 거쳐서 출력되는 항목을 말합니다. 
즉, 내부에서 어떤 처리를 한번 한 다음에 화면에 출력되는 내용이라고 생각하면 됩니다. 

반면에 외부조회(EQ)는 단순히 내부논리파일이나 외부연계파일에서 데이터를 가져와서 그대로 출력하는 경우를 말합니다. 

이러한 숫자들을 모두 계산한 다음, 각각의 기능에 입력하면 대부분의 FP 계산 엑셀파일에서는 자동으로 FP를 계산해 주게 됩니다. 
그리고 보정 계수를 입력하면 되는데, 각각의 항목을 살펴보면 그리 어렵지 않게 입력할 수 있으니 
실제 현업에서 사용하고 있는 FP 엑셀파일을 확보해서 내용을 살펴보시기 바랍니다. 

정보통신산업진흥원에서 제공하는 FP에 대한 문서는 다음과 같이 첨부하니 활용하시기 바랍니다. 
기능점수(Function Point)산정 및 활용 방안.pdf


더 알아보기

CAGR(연평균 성장률)에 대한 정리

연평균 성장률을 계산하는 방법에 대해서 살펴보세요.

투자 수익률 분석 IRR과 NPV

프로젝트 예산 배정 및 수행 검토를 위한 IRR과 NPV에 대해 살펴보세요.


사업 계획의 효율적 관리 린 캔버스

1장의 사업계획서 린 캔버스로 효과적인 사업 계획을 해 보세요.

린 캔버스의 모델이 된 나인 블락스

비즈니스 모델 설계를 위한 nine blocks에 대해서 살펴보시면 좋을 듯 합니다.

기획안 작성 요령

기획안을 만들 때 참고할 수 있는 내용입니다.





Trackback 0 And Comment 2
  1. 꼼즈 2012.04.26 17:37 address edit & del reply

    좋은 글들이 많이 있는 블로그네요 ^^
    잘 읽고 갑니다..

    • 미니~ 2012.04.26 19:45 신고 address edit & del

      @꼼즈님 나중에 제가 참고할 수 있도록 했던 일들을 정리하ㄴ는 블로그라고 보시면 되요. 자주 들려서 댓글이랑 많이 남겨주세요. ^^

PSA의 원칙과 실천단계

|




문제를 해결하는 방법이란 글에서 맥킨지 문제 해결의 기술에 대해서 대략적으로 이야기했습니다.
이 책을 기반으로 2009년 새해를 맞이하면서 생각해 볼 점들을 서술하도록 하겠습니다.

현대사회를 살아가면서 정말 필요한 것이 무엇일까요?
책에서는 가장 중요한 것이 논리적 사고 (logical thinking)이라고 합니다.
논리적 사고의 회로를 가지고 있다면, 어떤 상황 어떤 문제도 해처나갈 수 있는 지혜를 얻을 수 있을 것이고
모든 일에 자신감을 가지게 될 겁니다.
여기에 영어와 같은 어학과  IT 기술들을 활용할 수 있는 능력까지 있다면 최고의 인재가 될 수 있을 거라고 하네요.

그렇다면, 사회생활을 하면서 발생하는 수많은 문제점들을 논리적 사고를 이용해서 어떻게 해결할 수 있는지 정리해 보도록 하죠..

PSA(Problem Solving Approach)의 원칙


1. 모든 문제는 해결이 가능하다는 신념을 가진다. 


해결 할 수 없다고 생각하는 순간 몸과 마음은 거기에 따라가게 된다는 겁니다. 자신감이 없다면 어떤 문제도 결코 해결할 수 없는 것이죠..
실제 제가 함께 일한 개발자 중에 일은 잘 못하는 듯 한데 자신감 하나는 충만한 친구가 있었고, 반대로 능력은 괜찮은 듯 한데 부담감을 너무 많이 가지고 내가 할 수 있을까? 걱정부터 하는 친구가 있었습니다.
1~2년이 지난 후, 실제로 둘의 실력차이는 엄청나게 커졌습니다. ^^ (당연히 앞의 친구가 더 많은 능력을 보유하게 되었지요.)

2. 만약에 상황이 이렇게 된다면 어떻게 행동하거나 반응하면 좋은지 생각한다.


흔히 상황이 좋아지면 서로 공을 누가 세웠나를 논하고, 반대의 경우에는 누구에게 벌을 줄 것인지를 생각합니다. 그러나 PSA에 있어서는 상황의 좋고 나쁨에 따라 상벌을 논하기보다는 그 상황을 어떻게 해쳐나갈 수 있는지를 미리 고민해야 한다는 겁니다.

3. 원인과 현상을 혼동하지 말아야 한다.


원인과 현상을 구별하지 못하는 사람은 문제가 너무 많아서 해결하지 못한다는 이야기를 많이 한다고 합니다. 하지만 현상 하나에 일일이 대처한다면 그것이야말로 대책 없는 일이 될 수 있습니다.
즉, 원인을 포착하지 못하면 문제는 절대로 해결될 수 없겠지요..
실제 프로그래밍할 때 간단한 오류 하나 때문에 밤을 지샌적이 있을 겁니다. 이처럼 문제의 원인은 하나인데 여러가지 현상들을 모두 문제라고 생각함으로써 오히려 해법을 어렵게 가져가는 경우가 많이 있을 겁니다.

PSA(Problem Solving Approach)의 실천단계



1. 더해서 100이 되는 질문으로 문제의 원인을 찾는다.


앞에서 원인과 현상을 구별하는 것이 중요하다고 이야기했습니다. 원인을 찾기 위해서는 항상 더해서 100이 되는 질문을 치밀하게 만들어야 한다는 겁니다.

2. 문제의 본질을 찾았으면 가설을 세운다.


1번 질문을 통해 원인의 범위를 좁혀놨다면, 이제 그 원인에 대한 가설을 세워야 합니다. 아직 정말 원인인지 확실히 알지 못하므로 증명을 위해서 가설을 세워보는 겁니다.

3. 가설을 실증하는 데이터를 수집하고 증명한다.


앞에서 세운 가설을 증명하기 위해서 A=B, B=C이면 A=C라는 전이법칙을 사용합니다. 이를 위해 다양한 소스로부터 데이터를 수집하고 증명하는데 활용합니다.

PSA(Problem Solving Approach)의 4가지 프로그램


PSA는 프로세스(흐름)으로 수행하는 것이 바람직합니다.
즉, 첫째 필요한 정보를 구분하고, 둘째 수집된 정보의 의미를 이해하고, 셋째 핵심이 무엇인가를 파악하는 것이 중요합니다. 인터넷이 보편화된 현재에는 정보가 너무 많습니다. 이런 정보 중에서 정말 필요한 것이 무엇이고 그것이 내포하고 있는 핵심이 무엇인지를 파악하는 능력이 중요하다는 것이죠..

이를 위해서 PSA의 네가지 단계를 설명하고 있습니다.

1. 문제를 둘러싸고 있는 주변 환경을 이해


주변 환경을 볼 때는 항상 전체를 본 후 세부적인 내용으로 이해해야 한다고 합니다.
지나치게 세부적인 것 부터 볼 경우, 전체를 이해하지 못하는 경우가 종종 있다고 하네요..

그리고 항상 핵심이 무엇인지를 꼭 염두에 두고 작업을 해야만 성과물의 가치를 높일 수 있습니다.
이것저것 많이 한 것 같은데 핵심이 없다면 아무것도 안한 것과 다를바 없겠죠.

2. 효과적인 정보 수집 방법을 파악


기대의 매니지먼트라는 말이 있다고 합니다. 상대방의 기대 수준을 알면 그보다 높은 수준의 결과물을 만들 수 있게 된다는 것이죠.. 정보를 수집하는데 있어 자신이 여기에서 얻고자 하는 기대치가 무엇인지, 상사가 요구하는 기대치가 무엇인지를 알고 접근하면 좀 더 빠르고 정확하게 정보를 수집할 수 있다는 겁니다.

3. 데이터를 차트로 표현


어른들은 숫자를 좋아합니다. 즉, 숫자를 이용하면 설득력을 높일 수 있게 됩니다.
이런 숫자를 차트화 한다면 좀 더 이해력을 높일 수 있을 것입니다.

이런 차트를 작성할 때 알아 두어야 할 9가지 포인트를 정리합니다.
- 간단하고 알기 쉽고 보기 좋을 것
- 1차트에 1가지 메시지만
- 메시지와 차트가 일치하고 있을 것
- 항목은 5가지 이내로 압축하고 중요도가 낮은것은 '기타'에 넣을 것
- 항목의 순서를 고려하여 배열하고 중요한 것은 강조 처리할 것
- 사용하는 데이터의 기간을 일정한 간격으로 할 것
- 데이터의 연도와 단위를 명확히 할 것
- 보충 정보로 주의 사항이나 출처를 정확하게 기재할 것
- 마지막으로 완성품인지 아닌지를 확인할 것

4. 프레임워크를 통해 생각


문제 해결을 하는데 있어 안좋은 습관이 예단을 가지고 사물과 현상을 파악하고 예단을 가지고 정보를 취사 선택하며, 그리고 사물과 현상을 해석하는 것이라고 합니다.
이런 버릇을 없애고 사물과 현상을 객관적으로 이해하는 것을 도와주는 것이 프레임워크라는 겁니다.

프레임워크에 대해서는 다음에 다시 논의하도록 하겠습니다.

이상으로 PSA에 대해서 정리해봤습니다. ^^
나중에 문제가 발생했을 때, 어떻게 처리해야 할지 기억할 수 있도록 정리해 두는 거네요~

그럼. 제 블로그에 오시는 모든 분들 새해 복 많이 받으세요!!





Trackback 0 And Comment 0

프로젝트 팀원 역할 어떻게 설정해야 할까요?

|




프로젝트 관리자가 관리해야 할 항목은 보편적으로 다음의 9가지를 이야기 합니다.
- 품질관리          - 범위관리         - 위기관리          - 통합관리
- 일정관리          - 원가관리         - 인력관리          - 의사결정          - 구매관리

모두 중요합니다만, 프로젝트를 진행하면서 느끼는 점은 결국 사람이 만든 문제는 사람이 해결해야 한다는 점입니다. 즉 인력관리가 가장 복잡하면서도 어렵지 않나 생각합니다.

프로젝트 관리자가 되면, 프로젝트 수행을 위한 팀원을 적든 많든 배정받게 됩니다.
물론 슈퍼맨을 배정받으면 좋겠지만, 대부분은 일반적인 개발자를 만나게 될 겁니다.

이런 경우, 진정한 리더는 팀원들 자체에 신경쓰기 보다는 그 팀원들의 가능성을 식별해야 한다고 합니다.

가능성....

Project Management - A systems approach to Planning, Scheduling, and Controlling이란 책에 보면 프로젝트 관리자가 마주치게 되는 팀원들의 역할을 설명하고 있습니다.

즉, 협력적인 역할을 하는 사람도 있고 반면에 부정적인 역할을 하는 사람도 있다는 것이죠..

부정적인 팀원들의 역할을 방해하고 협력적인 팀원들의 역할을 극대화 시키는 것이 바로 프로젝트 관리자의 중요한 역할이라는 겁니다.

먼저 부정적인 가능성을 가진 팀원들의 성향을 살펴보죠..

 침략자  팀원들을 비판하고 아이디어에 이의를 제기하며 자존심을 꺽는다.
 지배자  조정하고 (업무를) 인수받으려고 시도한다.
 악의 옹호자  모든 사물에서 결점을 찾아내고 모든 아이디어에 이의를 제기한다.
 문제에 대해 갈팡질팡 하는 팀원  아이디어 사이를 왔다 갔다 하며 초점을 맞출 수 없도록 불균형을 조장한다.
 인정을 받아내려는 팀원  항상 지위에 대해 논쟁하고 성공의 공로를 차지하려고 시도한다.
 탈퇴자  참여하지 않고 정보를 공개하지 않는다.
 방해자  계획이 진행되지 않는 것에 대해 여러 가지 이유를 댄다.

이어서 협력적인 가능성을 가진 팀원들을 살펴보면 다음과 같습니다.

 선창자  새로운 아이디어를 찾고 "한번 해보자"란 말을 사용한다.
 정보 탐색자  보다 정보로 무장하려고 노력하고 자원과 지원 데이터를 찾는다. 팀의 이익을 위한 연구를 한다.
 정보 제공자  자신이 알고 있는 것을 공유하여 팀의 지식을 증대시킨다.
 촉진자  다른 사람들의 아이디어에 대해 눈에 보이는 지원을 보여준다.
 분류자  모든 사람이 이슈나 의사결정 사항을 확실히 이해하도록 도와준다.
 조화자  팀 사이의 단결된 감정을 형성한다.
 문지기  모든 정보가 적절하고 팀이 당면하고 있는 이슈에 대해 집중하도록 보증한다.

정리하면서 보니 역시 사람에게는 양면성이라는 것이 존재하는 듯 합니다.
저 역시 문제에 대해 갈팡질팡 하면서 동시에 정보 제공자로서의 역할을 하는 듯 합니다.

결국은 팀원들의 협력적인 가능성을 극대화시키고 부정적인 가능성을 최소화 시킬 수 있는 능력이 필요하다는 것이겠죠..

여러분은 어디에 속하는 팀원이라고 생각하나요?




Trackback 0 And Comment 0

프로젝트의 성공 요인 분석 #2

|



지난 글에서 프로젝트 성공 요인 중 변경관리, 희의관리, 이해관계자, 변화관리에 대해서 살펴봤습니다.
이번에는 이슈화, 리스크관리, 인적자원, 현실과 지표의 괴리에 대해서 알아보겠습니다.

다시 한번 출처를 언급하면 2004년 월간 시사컴퓨터에 기고된 천장락 교수님의 글을 정리해서 옮겨놓은 것입니다.

5. 사소해 보이는 문제도 '이슈화' 하자

프로젝트를 진행하다가 여러 가지 사정으로 계획과는 다르게 진행되거나, 계획대로 진행하기가 곤란한 문제가 발생했을 때 이슈가 발생했다고 합니다. 또 어떤 것이라도 일정에 차질을 주게 되면 이슈로 인식해야 한다고 합니다.

이러한 이슈를 관리하는 절차는 다음 6단계로 되어 있다고 합니다.

이슈 발생 인지 -> 이슈 분류 -> 대응 방안 수립 -> 대응 방안 실행 -> 실행 모니터링 -> 이슈 종결 내용 공지

이슈가 문제가 되면 리스크(위험)이 됩니다.
그럼에도 불구하고 이슈가 발생할 것 같으면 쉬쉬하고 내부적으로 해결해 보려는 노력을 많이 합니다.
프로젝트에서는 이슈가 언제든지 발생할 수 있습니다. 이런 문제를 내부에서만 조용히 해결하려다 더 큰 문제가 많이 발생할 수 있습니다.
사소한 이슈라도 제대로 파악하고 챙기는 프로젝트 관리자가 되어 보시기 바랍니다.
6. 프로젝트의 조기 경보기 "리스크 관리"

리스크를 프로젝트나 프로젝트 내의 일부분이 정해진 기간 내에 주어진 예산으로 완료되지 못할 위기에 빠질 수 있는 정도나 기대한 성과가 달성되지 못할 가능성이라고 정의하고 있습니다.

프로젝트 특성상 발생할 수 있는 리스크에 대해서 비슷한 프로젝트를 진행한 경험에서 축적된 지식으로 예측할 수 있으며, 이렇게 예측된 리스크를 관리 우선 순위별로 분류해 리스크 관리 체크 항목을 가지고 리스크를 관리해 나갈 수 있다고 합니다.

그래서 미리 막을 수 있는 대응책과 실제 발생했을 때 처리 방법이 있어야 한다고 이야기 합니다.
또한, 지표를 통해 리스크를 지속적으로 모니터링 할 수 있어야 함은 기본사항이구요..

앞에서 리스크/위험 관리에 대해서는 #1, #2로 정리한 내용이 있습니다.
리스크 완화, 회피, 모니터링, 관리에 대해서 이야기 했었습니다.
이런 위험 관리는 모든 프로젝트에서 중요한 요소라고 다시 한번 강조하고 싶네요..

7. 인적 자원의 파악, 가볍게 여기면 큰 코 다친다.

의욕이 앞서 보유한 자원의 총량을 초과해 프로젝트를 수행하다 보면 프로젝트가 제대로 진행되기 어렵습니다.
특히 인적자원은 사람의 수 뿐만 아니라 그 사람이 보유한 역량의 수준까지도 파악해야 한다고 합니다.

또한 아웃소싱에 의존하는 비율도 미리 정한 것을 초과하지 않도록 해야 하는데, 이유는 추후 유지보수나 관리에 문제가 발생할 소지가 있기 때문입니다. 프로젝트의 핵심 업무는 내부 인력으로 처리하는게 바람직하다고 하네요..

프로젝트 뿐만 아니라 모든 일은 결국 사람이 해결할 수 밖에 없다고 봅니다. 프로젝트에 있어서 갑자기 인력이 교체되거나 역량이 부족한 인력으로 수행하게 되면 댱연히 문제가 발생할 수밖에 없을 겁니다.
아웃소싱에 의존하는 업체도 아웃소싱 인력의 능력에 따라 프로젝트의 성패를 맡겨야 하니 불안할 수밖에 없을 거구요..
8. 현실과 지표 사이의 괴리를 메우자

프로젝트를 진행하면서 나오는 몇 % 진행되었다는 숫자에 대한 문제점을 지적하고 있습니다.
산출물 기준으로 진척도를 계산하게 되면 외형은 확인할 수 있지만, 품질은 확인이 곤란하다는 겁니다.
그리고 개발자의 감으로 진척도를 이야기 하면 테스트에 대한 부분이 포함되어 있지 않으며 객관적이지 않은 진행 상황일 수밖에 없다고 합니다.

그래서 전체 진척도와 단계별 진척도를 별도로 관리하고 테스트와 검토 단계의 비중을 높여서 계산해야 한다고 합니다.

어디서 보니까 어른들은 숫자를 참 좋아한다고 합니다. 모든 데이터를 정량화 하는 것은 프로젝트 관리에서도 중요한 작업임에 틀림없습니다.
그러나 그 정량화에는 반드시 현실이 제대로 반영되어 있어야 합니다. 그러기 위해서는 기준이 중요하고, 프로젝트에서도 개발 속도 뿐만 아니라 품질까지도 포함해야 한다는 것이죠..

이상으로 프로젝트의 성공 요인에 대해 정리해봤습니다. 일반적으로 생각하는 부분과 큰 차이가 없어서 정리해봤습니다.

여러분은 어떻게 생각하는지요? 이 외에도 중요한 요소가 있다면 댓글 부탁드립니다.




Trackback 0 And Comment 0

프로젝트의 성공 요인 분석 #1

|



2004년 5월 ~ 12월까지 월간 시사 컴퓨터에 연재된 천정락 교수님의 프로젝트 성공 요인 분석이란 자료가 있습니다.
4년여의 시간이 지났지만, 아직도 현재 진행하고 있는 IT 프로젝트에도 도움이 되는 이야기 인 듯 하여 정리해서 옮겨 봅니다.

1. 업무 변경 관리로 프로젝트 성공률을 높이자.

첫번째로 이야기 한 것은 변경 관리입니다. 프로젝트의 범위나 현업의 업무가 변경된 경우, 의사결정자들과 프로젝트 수행자들이 모여 업무 변경 관리 위원회를 만들고 체크해 나가야 한다는 이야기 입니다.

방법으로는 업무가 변경될 때마다, 단계별로, 프로젝트 막바지에 변경하는 방식이 있는데요
변경될 때마다 하는 것은 번거롭고 프로젝트 진행을 더디게 할 수 있구요.
단계별로 수행하는 것은 프로젝트가 잠시 멈추게 되므로 미리 일정을 반영해서 변경관리를 해야 한다고 합니다.
마지막에 일시에 수행하는 것은 프로젝트가 긴 경우, 업무 변경의 양도 많고 시간도 오래 걸리므로 주의해야 한다고 하네요..

어쨌든 추가 비용이 들더라도 업무 변경 관리는 어떤 형식으로든지 해야 합니다.
보통 프로젝트 수행시에 보면, 마지막에 설계 문서를 한꺼번에 다시 고치는 경우가 가장 많은 것 같습니다.
즉, 프로젝트가 끝난 후에 개발 결과물에 맞추어서 설계문서를 다시 만드는 것인데요..
실질적인 변경관리라고 볼 수는 없다고 봅니다.

정말 성공하는 프로젝트를 만들고 싶다면, 설계를 변경하는 것에 대한 위험성을 고객이나 프로젝트 수행자 모두 인식하고 초기 설계부터 신중을 기해야 할 것입니다.
2. 회의도 관리가 필요한 시대다.

회의로 인해 낭비되는 시간의 가치에 대해서 이야기 하고 있습니다.
회의를 줄이기 위해 단순한 정보 공유는 이메일이나 인트라넷 게시판을 활용하고, 화상회의 같은 것을 충분히 활용하자는 겁니다.

만약 회의를 진행한다면, 미리 회의 목적과 내용을 회의 참석자에게 알리고, 회의의 시작과 끝나는 시간을 정해서 준수하고, 회의 끝 부분에 안건과 결론을 정리하고, 결론이 난 부분을 해당 부서나 팀에 효과적으로 전달해야 한다고 하네요..

회의가 많은 기업은 그리 성공하지 못한다는 이야기를 들은 적이 있습니다.
물론 회의라는 것이 매우 중요한 것이지만 그만큼 잘못 사용하면 탁상공론에 실행이 뒷받침되지 않는 조직이 될 가능성도 높겠죠..
3. 이해관계자를 '내 편'으로 만들어라

이해관계자라 하면 고객과 같은 '프로젝트 스폰서', 프로젝트를 수행하는 '프로젝트 실행자', 프로젝트에는 직접 관여하지는 않지만 영향을 주거나 받을 수 있는 '외부 이해관계자'를 이야기 합니다.

이런 이해관계자를 명확하게 파악하고, 각자의 입장에서 프로젝트 수행에 대한 득실과 주장의 정보를 파악하고, 프로젝트에 대한 영향을 분석하고, 대응전략과 구체적인 실행방안을 세우고, 모니터링 및 피드백을 해야 한다는 겁니다.

여기에서는 주로 외부 이해관계자에 대한 이야기를 하고 있는데요..
저는 일반적으로 IT 프로젝트에 있어서 고객에 초점을 맞추고 싶습니다. 고객이라 하면 외부고객과 내부고객으로 나눠 볼 수 있을 겁니다.
내부에 같이 프로젝트를 진행하는 사람들도 하나의 고객이라고 생각하고 내편으로 만들어 업무를 진행한다면 프로젝트 진행이 좀 더 수월해지지 않을 까 합니다.
4. 프로젝트 연착륙 뒤엔 변화관리가 있다.

여기에서 변화관리는 위의 변경관리와 다른 이야기 입니다. 변경관리가 프로젝트 진행 중에 발생하는 변경 요소를 관리하는 것이라면, 변화관리는 프로젝트 완료 후 새롭게 적용되는 변화에 대한 관리를 말합니다.

프로젝트를 완료하더라도 적용해야 하는 직원들의 새로운 환경이나 제도에 대한 저항을 받을 수 있다고 합니다. 그래서 실행 과정에서 직,간접적으로 영향을 받게 되는 조직원과 고객으로부터 불편을 사게 되면 기대한 만큼의 성과를 내기도 어렵고, 조직원과 이해관계자들한테 성공했다는 평가를 받기 힘들다고 합니다.

변화를 적극 수용하고 변화에 대한 저항을 극복하며, 변화 계획을 세우고 그 계획을 차질 없이 성취해 나가기 위한 변화 관리가 필요하다고 이야기 하고 있습니다.

실제로 어렵게 프로젝트를 통해 결과물을 만들어도 제대로 활용하지 않으면 무용지물일 겁니다.
결국 만드는 것만이 최종 마무리가 아니라 제대로 필요한 곳에 적용하는 것이 성공적인 프로젝트의 마무리가 아닐까 합니다.
이어서 나머지 이슈화, 리스크관리, 인적자원, 현실과지표에 대해서 정리해 보도록 할께요~
프로젝트 관리 알면 알수록 배울게 많은 것 같습니다.




Trackback 0 And Comment 0

위험관리(Risk Management) 프로세스 #2

|



지난번에 위험(risk)의 원인, 식별, 위험관리 프로세스에 대해서 이야기했습니다.

위험이라고 하는 것은 드러나기 전에 처리하는 것이 가장 좋기 때문에 이런 위험 관리가 필요합니다.
실제로 위험이 발생한 이후 처리한다면 프로젝트에 타격도 그만큼 크겠죠..

4. 위험 관리

그래서 이번에는 위험을 관리하는 방법에 대해서 먼저 살펴보도록 할께요..
위험을 관리한다고 해서 모든 위험요소를 제거할 수는 없을 겁니다.
그러나 위험관리를 통해서 위험을 회피하거나 위험요인을 줄이거나 위험 발생시 비상대책을 수립하는데 도움이 될 수 있습니다.
이러한 위험관리에 대해서 정리해 봅니다.

1) 획득 (Procurement)
프로젝트 수행 중에 기술적인 위험요소가 발생한다면, 그런 기술을 가지고 있는 사람이나 조직을 구해서 해결하는 겁니다.
언뜻 보기에는 가장 쉬운 방법 같지만, 실제 프로그래밍에서는 추가 비용이 들어가는 문제가 나올 수 있습니다.
뿐만아니라 프로젝트 참여자가 늘어나면서 발생하는 Communication overhead도 무시할 수는 없을 겁니다.

2) 비상계획 (Contingency Planning)
실제 위험이 발생되었을 때, 위험을 완화하거나 피해를 최소화 하기 위해서 수립하는 계획을 말합니다.
발생 위험의 원인별로 비상 시나리오를 작성하여 위험 발생시 즉각 조치를 취할 수 있도록 하는 것도 포함합니다.

비상조치계획에는 위험항목, 위험정도, 위험발생부위, 비상대책전략, 예상되는 비용, 대책별 추진 담당자, 비상 대책 수행일정 등의 정보를 포함해야 한다고 합니다.

3) 대체 전략 (Alternative Strategies)
예정된 방법이 아닌 다른 방법으로 위험요소를 예방하거나 피하는 방법입니다.
예를 들면, 초기 단계에 위험요소에 대한 설계 변경을 함으로써 구현단계에서 발생할 수 있는 설계위험을 줄이는 것을 들 수 있습니다.

4) 보험 (Insurance)
외주와 같이 외부와 공동 작업을 해야 하는 경우, 발생할 수 있는 위험 요소로 부터 보호받기 위한 건데요..
실제 보험에 드는 걸 말합니다. 요즘은 보증보험증권인가 하는 것을 받기도 하죠..

5) 위험 관리 계획 (Risk Management Plan)
프로젝트 전 과정에서 발생할 수 있는 위험들을 관리하는 절차를 문서화 한 것을 말합니다.
RMMMP(Risk Mitigation, Monitoring and Management Plan)이라는 위험 완화, 모니터링 관리 계획에 포함할 수도 있습니다. RMMM에 대해서는 밑에서 한번 더 정리하도록 하죠..

6) 계약 협정
불명확성이야말로 프로젝트를 실패로 이끄는 지름길입니다.
그래서 이런 불명확성을 계약시에 협의하거나 조건을 부여하는 것을 말하는데요..

글쎄요.. 중소기업의 경우 실제 프로젝트에서 이렇게 할 경우, 계약을 성사시킬 수 있을지 의문이 듭니다.
일정 규모 이상이 되는 기업에서는 제안 단계에서 이런부분에 대해 심의하는 팀이 별도로 있는 걸로 알고 있습니다.

7) 위험관리 및 모니터링
계획만 세워놓고 실제 위험이 발생한 것을 알아차리지 못한다면 아무 소용이 없겠죠..
위험은 초기에 발견하고 해결을 해야 그 피해를 최소화 할 수 있습니다.
그런 의미에서 위험 관리 계획 못지 않게 중요한 것이 위험 모니터링입니다.

또한, 고객의 정책 변경으로 위험요소가 없어져 버리거나 솔루션 업그레이드로 인해 기술적 위험요소가 사라지는 등 초기에 위험요소라고 판단했던 부분이 제거되기도 하므로 모니터링을 통해서 지속적으로 관찰해야 할 겁니다.

5. 위험 완화, 모니터링 및 관리계획(RMMMP - Risk Mitigation, Monitoring and Management Plan)

앞서 설명한 TL 9000에 보면 프로젝트 기획 활동 중에 위험관리 및 우발사건 계획서(Risk Management and Contingency Plan)의 작성을 요구하고 있습니다.
프로젝트 관리자는 이 요구사항을 만족하기 위해서 RMMMP를 작성할 수 있습니다.

RMMMP는 앞에서 이야기한 개념들을 토대로 프로젝트 성향에 따라 적합하게 작성하고, 작성된 계획에 따라 위험관리를 수행하면 됩니다.
실제 프로젝트에서 보면 계획서와 실제 활동이 따로 수행되는 경우가 많은데요..
RMMMP뿐만 아니라 모든 프로젝트 관리 프로세스에서 초기 계획의 수정과 보완으로 지속적으로 활동과 맞춰주는 작업이 필요합니다. (말은 쉽지만, 실제 행동이 어려운 부분이죠.. -.-)

RMMMP에 대한 템플릿이 있어 옮겨봅니다. 참고하시면 도움이 될 듯 하네요..

1.0 서론
    이 부분은 RMMMP의 전체적인 개요를 설명한다.

    1.1 RMMM 활동의 범위 및 정도
        RMMM의 목표, 조직의 책임, 활동의 범위 및 정도를 기술한다.

    1.2 위험관리 조직 역할
        위험관리를 위한 책임을 가지고 있는 사람이나 조직을 기술한다.

2.0 프로젝트 위험들
    이 섹션은 이미 알려진 프로젝트 위험들을 기술한다.

    2.1 위험 테이블
        모든 위험들의 발생 확률 및 영향들을 테이블 형태로 제시한다.
   
        2.1.1 위험 M에 대한 기술
            위험 M을 관련된 조건에 따라 기술한다.

        2.1.2 위험 M에 대한 발생 확률 및 영향
            위험에 대한 발생 확률과 영향도를 기술하며, 각각의 위험을 M개까지 기술한다.

    2.2 위험 정제
        높은 발생 확률의 위험과 높은 영향을 미치는 위험들만을 구분하여 기술한다.

3.0 위험완화, 모니터링 및 관리
    이 섹션은 각각의 위험에 대한 위험 완화, 모니터링 및 경영 활동에 대해 기술한다.

    3.1 위험 M을 위한 완화
        위험을 어떻게 피할 수 있는지를 기술하며, 각각의 위험에 대해 M개까지 기술한다.

    3.2 위험 M을 위한 모니터링
        어떤 조건에서 M이 증가하거나 줄어드는지를 결정하기 위한 모니터링 방법에 대해 기술한다.

    3.3 위험 M을 위한 관리
        위험 M이 발생할 때 어떤 비상조치 계획에 따라 관리할 것인지를 기술한다.

4.0 기타 특수 조건들
    프로젝트에 치명적인 위험을 야기하는 특수한 기타 조건들에 대해 기술한다.

6. 위험 정량화

RMMMP를 보면 중간에 "위험 M에 대한 발생 확률 및 영향"이란 말이 나옵니다.
즉, 위험(Risk)을 정량화 해서 발생 확률이나 영향을 추출해야 한다는 것인데요.
이것을 정량화 하는 것이 그리 쉬운 작업은 아닐 겁니다.
그러나 대략적인 느낌만으로 위험을 감지하는 것보다는 수치화해서 체계적으로 관리하는 것이 바람직 하겠죠..

정량화라고 하는 것이 복잡한 요소가 많아서 빼려다가 그냥 정리해 봅니다.
나중에라도 도움이 되겠죠.. ^^

위험을 정량화 하기 위한 먼저 해야 할 작업은 위험 표를 만들어보는 겁니다.
어떤 위험들이 존재하고, 첫번째 글에서 설명한 어떤 위험인지 분류하고, 위험이 발생할 확률은 어떻게 되고, 어떤 영향을 미치는지 정리해 보는 겁니다.

먼저 예를 보고나서 정리를 하도록 하죠..

사용자 삽입 이미지


분류는 다음과 같습니다.
PS : 프로젝트 크기 위험
ST : 엔지니어의 위험
DE : 개발환경에 대한 위험
BU : 비즈니스의 위험

위험 표에서 영향 부분의 값을 결정하기 위해서 고려해야 할 사항은 다음 세가지 입니다.
위험의 성질 : 위험이 발생할 경우 일어날 수 있는 사건들
위험의 범위 : 위험이 존재하는 전체 구역을 나타내는 범위
위험의 타이밍 : 위험이 언제 얼마 동안 영향을 미치게 될지 고려

그래서 영향 부분의 값을 결정할 때는 1 - 재앙적인, 2 - 심각한, 3 - 별로 중요하지 않은, 4 - 무시할 수 있는 정도로 구분합니다.

위 표를 토대로 위험의 발생확률과 영향에 대한 그래프를 다음과 같이 그려서 위험 관리 포인트를 결정할 수 있습니다.

사용자 삽입 이미지



위험 영향과 확률은 관리 관점에 서로 다른 영향을 줍니다. 큰 영향을 미치더라도 확률이 매우 낮은 위험 인자에 대해서는 많은 관리시간을 소비하지 말아야 한다고 합니다. 그러나 높은 확률에 중간 정도의 영향을 미치는 위험과 낮은 영향력을 갖지만 발생 확률이 높은 위험은 반드시 중점 관리하여야 합니다.

앞의 표를 보면서 어떤 생각이 들었나요?
정량적이라면서 수치를 결정하는 방식에서 기준이 없다고 느끼지 않으셨는지요?

그래서 위험의 발생확률을 결정하기 위한 방법들이 여러가지가 있습니다.
수학 및 통계적 계산 방법을 사용하는 몬테 카를로 기법(Monte Carlo Method)가 있구요..
의사결정을 위한 의사결정 나무 기법(Decision Tree Method)가 있습니다.
이런 방법에 대해서는 나중에 기회가 되면 다시 한번 정리해 보도록 하죠..

좀 쉽게 계산할 수 있는 방법으로는 다음과 같은 공식을 적용할 수도 있다고 합니다.

R = P(h)*P(a)*l

여기서 R은 위험이고, P(h)는 위험의 발생 확률, P(a)는 사고나 손실을 유발하는 위험의 발생 확률, 그리고 l은 손실을 양을 나타냅니다.

아니면 아예 정량적인 방법이 불가능할 경우, 위험 요소를 정성적으로 판단하는 것이 유용하게 사용될 수도 있습니다.
정성적인 방법은 위험 요소에 따라 수치가 아닌 A, B, C, D로 나누고 관리하는 형태를 취하면 된다고 하네요..

이상으로 위험관리에 대해서 대략적으로 정리 해 봤습니다.
도움이 되었는지 모르겠네요~ 앞으로 블로그가 약간 아카데믹해지더라도 이해해 주세요 ^^




Trackback 0 And Comment 0
prev | 1 | 2 | 3 | 4 | next