강팀장의 Web E.Y.G(웹이야기)

 프로젝트를 관리하는 방법은 여러가지가 있는 것 같습니다.
우리가 흔히 많이 알고 있는 일정을 관리하는 방법, 산출물 관리 방법, 인력을 관리하는 방법, 비용을 관리하는 방법...

그런데... 이런 것들을 보면 거의 비슷한 말들로 통하는 것 같습니다. 비용~!!

일정을 관리하는 것도 결국 비용을...
산출물을 관리하는 것도 결국 비용을...
인력을 관리하는 것도 결국 비용을...

약간의 표현과 관리 관점은 차이가 있을 수 있으나, 최종적으로 프로젝트를 제대로 관리하기 위한 방법 중 하나인 것 같습니다.

그래도 가장 많이 이야기가 대두되고, 프로젝트가 꼭 IT에만 있는 것이 아니기 때문에... 순수 프로젝트 관리라는 의미에서 본다면 비용으로 관리되는 것이 정통적인 방법이 아닐까 합니다.

프로젝트 관리에서 비용, 예산(Budget)으로 관리해 나가기 위해 알아야 할 몇가지 단어와 정보가 있어야 하겠습니다.

(개인적으로... 이 부분을 정확히 알고... 프로젝트를 바라보면... 눈이 훨씬 넓어지는 것 같았습니다.)

 

u 계획요소	• WBS (Work Breakdown Structure) : 작업분류체계 • CA (Control Account) : 공정&비용의 통합관리 기본 단위 • PMB (Project Management Baseline) : 프로젝트관리 기준                                                       (공정&비용의 통합관리 기준) • BAC (Budget At Completion) : 예산 내 성공여부를 판단하는 기준(Baseline)
u 측정요소	• BCWS (Budget Cost for Work Scheduled) 계획 예산  PV (Plan Value)             계획된 일정상 작업 종료하는데 드는 예산 • BCWP (Budget Cost for Work Performed) 할당 예산 EV (Earned Value)              수행된 작업에 할당된 예산 • ACWP ( Actual Cost for Work Performed) 실행된 비용 AC (Acutal Cost)              수행된 작업에 대해 실제 실행된 비용
u 분석요소	• SV (Schedule Variance) : 현 프로젝트 일정진척 상황 = BCWP – BCWS • SPI (Schedule Performed Index) : 진척율 = BCWP/BCWS • CV (Cost Variance) : 계획대비 실적 차이 = BCWP – ACWP • CPI (Cost Performed Index) : 실적율 = BCWP/ACWP
u 예측요소	• BCWR (Budgeted Cost for Work Remained) : 잔여예산 = BAC – BCWP • ETC (Estimate to Completion) : 잔여예산 원가 = BCWR / CPI • EAC (Estimated At Completion) : 총 예산 원가 = ACWP + ETC

계획, 측정, 분석, 예측 이렇게 4가지 요소는 프로젝트 관리에서 프로젝트 관리자에게 올바른 판단과 빠른 결정을 도와주는 막강한 힘이 되어 줍니다.

각각의 수치에 대해서 어떻게 계산되어지나... 싶기도 하겠습니다..

그것보다.... 위의 4가지요소중, 분석요소를 통해... 프로젝트가 어떻게 진행되는가에 대해서 한번 알아보겠습니다.

(작년에 강팀장이 워크넷이라는 프로젝트를 한적이 있었습니다. 당시 SK에서 일명 할아버지 PM이 오셨는데.... 오랫동안 같이는 못했지만.... 밀고 나가는 추진력에 대해서는 한수 배우기도 했습니다. - 그 당시에 다른 팀원 및 PL들에게 "프로젝트는 말이야... 이렇게 되는거야.. S 자... S 자... 원래 이렇게 진행되는거야~!!!" 이렇게 힘주어 말하던 것이 기억납니다. 그때 알아 들은 사람도 있었겠지만, 분명 못 알아 들은 사람도 있을 겁니다. S자 그래프를 그려가며... 힘주어 말하던 할아버지 PM이 다 설명하진 않았지만... 왜 그렇게 되어야 하고... 그게 어떻게 된다는 것을 이해를 했을까 싶기도 합니다. 단지.. 진척율 측정을 하기 위해 다른 사람들은 이해한게 아닐까 하는 아쉬움도 들기도 합니다...)

그럼... 그래프를 가지고 한번 보겠습니다. (그래프를 어떻게 그리느냐.... 혹시 질문하시려는 분들 계실려나??? ㅡ.ㅜ 공부공부 공부만이 살길입니다. ^^)
할아버지 PM이 박박 소리치던.. 그 S자 곡선입니다.



먼저 그래프는 세로가 비용, 가로가 일정 또는 시간입니다. (40, 50, 60 은 그냥 계산해 보라고 붙이 금액인데... 40K = 40,000 이라는 뜻입니다.  그림 실력이 떨어져 조금 간격이 잘못 되었더라도 이해를...)
상단선인 노동예산은 예산의 Base Line 이라고 생각하면 되겠습니다. 뭐... 계약금과 비슷하긴 하지만, 정확히 계약금하고 틀린수도 있습니다. (회사가 처음부터 손해 보고 하고자 하는 프로젝트 경우 틀리겠습니다.) 마감시한은 프로젝트 끝 시점입니다.

BCWS 는 최종 프로젝트 끝날때까지 예산 그래프고... 어떻게 보면... 일정별 진척율이라고 봐도 됩니다. MS Project를 돌리면.... 이렇게 그래프가 생기죠.

1번 그래프 입니다.
결과적으로 말하면.... 일정은 늦어지고, 예산을 많이 들어가고.... 현재 프로젝트가 힘든 상황입니다. 많은 리스크가 동시 다발적으로 발생하고 있을 가능성도 높고.... 상급자부터... 최하위 팀원들까지 힘들어하고 있는 상태 입니다.

왜 그런지 한번 볼까요?
SV = BCWP-BCWS = 40k - 50k = -10k 입니다.
즉 지금 약 10,000달러치 일을 안했다는 것입니다. -10k 만큼 일정이 늦어지고 있다는 소리겠죠.

CV = BCWP-ACWP = 40k - 60k = -20k 입니다.
현재 초기 계획에 비해 더 들어가서 오차가 20k 를 오버하고 있다는 것입니다.

이렇게해서 그래프를 유추해 보면.... 돈은 더 많이 들어가고, 일정을 계속 늦어지고 있는 상태 입니다.



2번째 그래프 입니다.
위의 방법으로 한번 해석해 볼까요?
SV = BCWP - BCWS = 60k - 40k = +20k
지금 +20k 가 발생되었으니... 20k 만큼 일을 더 했다. +20k 만큼 일정이 빠르다 라는 것을 말합니다.

CV = BCWP - ACWP = 60k - 60k = 0k
0k 가 나온것 보니깐.... 돈은 제대로 나간 것입니다. (일을 많이 한 만큼 비용도 많이 나갔다는 의미겠지요. 하지만, 정직하게 돈이 나간거니깐.... 그나마 위안이긴 합니다.)
결과 : 일정은 앞서고 있고, 돈은 조금 더 나간듯 하지만 계획대로 지출된 프로젝트 입니다. 하지만 이대로 가다가 일정이 늘어지게 된다면... 나중에는 오버가 발생된 수 있는 위험수준에 도달해 간다는 것을 의미 합니다.
사람이 하는 일이 완벽할 수 없기 때문에... BCWP, ACWP 곡선이 x 자로 꼬인다면... 큰 문제가 되겠죠.



 3번째 그래프 입니다.
이제 여러분이 한번 해석해 보실래요???
정히 어렵다면... 아래를 클릭하시면 됩니다.

3번 그래프 해석 보기..

4번째 그래프 입니다.
이것도 한번 풀어보시는 것도 괜찮을 듯합니다.

4번 그래프 해석 보기..

  프로젝트 관리 - Worksmart Series Vol.1  

제임스 루이스 지음, 조진경 옮김, 한동환 감수
바쁜 기업 관리자를 위해 업무 현장에서 반드시 필요한 핵심 매니지먼트 스킬만을 담은 'WorkSmart' 시리즈 첫 번째 책. 기업 관리자들이 고도로 전문화된 다양한 분야의 프로젝트를 철저하게 실무 중심으로 관리할 수 있도록 단련시켜 주는 입문서다. 간단한 단계별 접근방법을 이용하여, 목표 전술부터 프로젝트 팀의 관리에 이르기까지 프로젝트의 모든 단계를 통제하는 법을 제시한다.

하나의 시스템 개발은 많은 사람이 현업을 통해 만들어내는 공동 작품입니다.
조각 그림을 맞춰 나가듯 많은 공동 작업자들이 각 부분의 조각을 하나씩 완성해 나가고 그것을 통합하여 그림판에 옮겨 놓는 작업 입니다.

이런 작업에서는 우선 밑그림을 그리고, 각 조각을 만들고, 조각을 다시 그림판에 올려 놓는 일련의 활동을 하게 됩니다.

개발 방법론도 이런 일맥 상통한 작업이라고 할 수 있습니다.

하드웨어의 발전에 비해 소프트웨어 발전은 뒤처져 왔습니다. 그 원인이야 여러가지가 있겠지만,  소프트웨어 및 시스템은 반세기 동안 하드웨어/인프라 발전을 따라가지 못하고 있는 것이 현실 입니다.
 
소프트웨어가 발전이 느렸던 이유중 가장 큰 이유는

정형화 되어 있는 하드웨어 비해 소프트웨어는 정형화되어 있지 않기 때문입니다.
정형화되어 있지 않다는 것은 하드웨어 보다 소프트웨어쪽이 사람에게 가깝기 때문입니다.
(시스템중에 하드웨어 보다 소프트웨어가 사람의 생활패턴에 접근되어 있는 것이고, 기계와 인간간의 인터페이스 역활을 하고 있습니다. )

인간과 접근되어 있다 보니, 인간의 변화(혹은 변심)속에서 정형화라는 자체가 어려울 수 밖에 없습니다.

정형화를 위한 부분보다 어떻게 인간의 변화에 정확하게 대응하느냐에 대한 연구가 더 많이 발생할 수 밖에 없었을 것입니다.

개발 방법론은 이런 근본적인 원인으로 인한 많은 문제점을 효율적인 해결을 위한 방법으로 더욱 발전하게 되었습니다.

- 소프트웨어 공학 등장배경 -

● 하드웨어 개발 비용에 비해 소프트웨어 개발 비용의 증가
● 새로운 시스템 개발 요구 및 수요 급증
● 요구 및 수요 급증 대비 개발자 생산성 저하
● 개발 인력 부족
● 개발 기술 미비
● 기존 소프트웨어의 유지보수 어려움

소프웨어 공학은 소프트웨어의 개발에 필요한 모든 측면을 공학적인 접근 방법으로 다루는 학문으로

- 주어진 기간 내에 프로젝트을 효율적으로 관리하는 방법
- 프로젝트에 투입될 비용(Cost)를 예측하고 인력을 관리하는 방법
- 사용자 요구사항(Requirement)을 정확히 분석하고 요구사항에 적합한 소프트웨어를 개발하는 방법
- 개발 과정의 산출물을 체계적으로 문서화(Documentation)하는 방법

중심으로 연구를 합니다.


이런 의미에서 개발 방법론의 기본 개념은 소프트웨어 공학에서 나온 것입니다.

개발 방법론이란 제품을 생산하기 위한 일련의 활동(Activity)와 산출물(OutPut)를 체계적으로 관리하는 일련의 활동이라고 정의할 수 있으며, 이런 활동을 소프트웨어 공학에서는 소프트웨어 프로세스라고 정의하고 있습니다.

일반적인 프로세스 활동은 4단계로 이뤄집니다.

1. 명세(Specification) : 기능과 운영상의 제약조건 정의
2. 개발(Development) : 명세를 만족하는 소프트웨어 개발
3. 검증(Validation) : 사용자가 원하는 소프트웨어인지 확인
4. 진화(Evolution) : 사용자 요구사항의 변화에 부응하는 소프트웨어 변경

소프트웨어 공학이나, 개발 방법론이나 요구사항에 부합되는 제품, 서비스를 생산해내는 활동에 초점이 맞춰져 있고,  발생 예견된 많은 위험(RIsk) 최소화 하는 활동을 위한 관리기법(Management)이 필요한 것입니다.




간혹 PM에 대해서 잘못 이해하고 있는 사람들이 많이 있습니다. 특히 웹에이전시의 PM는 그 역량에 대한 부분보다, 단지 클라이언트와의 접점을 위한 존재로만 인식하는 경우가 많이 있습니다.
그렇다보니, 기획자가 PM을 한다는 인식이 많이 가지고 있습니다.

PM은 관리자라고 해야 정확한 것입니다.
▶ 사용자(Client)의 요구사항과 프로젝트의 근본 방향을 정확하게 이해하고,
▶ 프로젝트 과업에 대한 일관성 있는 목표 달성의 책임을 가지고 있는 사람입니다.

프로젝트에 대한 전반적인 책임을 지기 위해서는 3가지의 중요한 역량이 있어야 합니다.



1. 일괄성
간혹 프로젝트를 하다 보면... 배가 산으로 간다는 말이 있습니다. 그 방향을 잃어 표류하는 배들은 난파될 확률이 높습니다. 초기반에 프로젝트의 배경을 이해하고 방향성을 갖추고 나면, 프로젝트 진행은 일괄성을 지녀야 합니다.
이 일괄성은 요구사항에 대한 부분이 가장 강합니다.

2. 단계성
일에는 순서가 있다고 말합니다. 각 단계에 대한 수행능력과 그 단계에 대한 조율을 적절하게 이뤄나가야 합니다.

3. 체계성
프로젝트를 진행하다 보면, 각 단계를 생략하는 경우가 많이 있습니다. 물론 상황에 따라 진행이 변화될 수 있겠으나, 모든 단계는 근거와 과정에 대한 이유가 존재하는 것입니다. 이런 단계를 거쳐 나갈때-변화가 되던 안되던- 체계적인 관리가 있어야 합니다. 특히 단계가 생략되는 경우에는 더욱 그렇습니다.


PM에 대한 이해가 낮을수록 프로젝트는 표류하여 난파될 가능성이 높습니다.

전쟁에서 많은 병사도 중요하지만, 병사들과 그들을 전쟁에 보낸 이들이, 중심에서 지휘하고 선장을 서는 장군이 어떤 존재인지를 이해해야지만, 일괄성을 단계성을 체계성을 보장 받을 수 있으며, 결국 전쟁에서 이길 수 있게 되는 것입니다.


기획자 = PM의 논리에서 벗어나야 합니다. PM은 누구나 될 수 있으나, 기본적인 지식을 습득되어야 합니다.

PM 는 개발/관리 방법론에 대한 지속적인 지식습득이 필요로 합니다.
집을 짓더라도, 토대가 제대로 잡히지 않는다면... 오래 가지 합니다.

얼마전 이런 쪽지를 받은 적이 있습니다.

"관리가 안되는 프로젝트 (대부분의 한국형 프로젝트)...."

어느 정도 경력도 갖추고 어느 정도 실력을 갖추었다고 자부하던 팀원에게 받은 쪽지는 강팀장에게 약간의 고민을 안겨 주었습니다.

한국형 프로젝트????

도대체 한국형 프로젝트란 무엇이지??
외국에는 다른 프로젝트를 수행하는 건가??? 아니면.. 다른 개발 언어로 개발하는 건가??? 무엇이 다른거지????

간혹 모임이나 동호회에서도 이런 부분에 대해서 토론을 하게 될때도 한국형 프로젝트와 비슷한 말들을 듣습니다.

"선진국의 프로젝트는 이렇게 되는데, 한국에서는 그렇지 못하기 때문에 실패 경우가 많은 거야...."

솔직히 강팀장은 그런 말들에 대해서 이해가 잘 가지 않습니다.
선진국이라고 말하는 부분... 한국형이라고 말하는 부분... 이런 말들은 너무나 상식적인 선에서 자주 나오기 때문에 강팀장 스스로도 혼란스러울때가 많습니다.

일전에... 블로그에 [프로젝트 실패의 원인] 이라는 글을 올린 적이 있습니다.

한국이라는 상황에 스스로 비관적 생각보다는, 어떻게 프로젝트를 효율적으로 진행할 것인가를 고민하는 것이 낫다~! 라는 것입니다.

선진국(?), 외국(?) 사례와 많은 연구 보고서를 보면 한국에서 프로젝트를 진행하면서 겪는 일들이 결코 한국이라는 상황때문에 일어나는 것이 아니라, 발전을 위해 한번은 경험해 보아야하는 과정 같은 것이라 쉽게 알 수 있습니다. - 물론 그런 과정자체를 겪어서는 안되겠지만...... -

이렇기 때문에..??... 결국 포기하는 것인가?? 당연히 실패?? 일정 지연....??  많은 문제점들을 정당화하고자 하는 것이 아니라...

지금 겪고 있는 현재의 상황을 너무 극단적으로 비판할 필요는 없을 것 같습니다.

실패를 최소화 하기 위한 많은 연구가 진행 중이고, 이런 부분에 대한 적용과 실무 진행등의 노력도 지속적으로 이뤄지고 있으니, 앞으로 더 좋아질거라 생각 됩니다.

굳이 "한국형" 이라는 굴레를 만들어 버린다면.. 그 또한 문제가 있지 않을까 생각합니다.

  소프트웨어 프로젝트에서의 리스크 관리  

톰 디마르코 외 지음, 김준식 옮김
2004년 졸트상(Jolt Winner) 수상작. 피플웨어의 저자 톰 디마르코와 티모시 리스터가 제안하는 소프트웨어 프로젝트 리스크 관리를 위한 가이드라인. 프로젝트의 불확정성을 반영한 리스크 계량화 방법을 제시한다.

  Rapid Development - 프로젝트 쾌속 개발 전략  

스티브 맥코넬 지음, 이해영 외 옮김
실제 최전방에서 싸우는 개발자와 관리자들에게 구체적인 사례와 문제 해결 방법을 제시하는 실탄을 제공한다. 풍부한 배경 자료, 다양한 사례 연구, 수백편의 논문과 책을 토대로 분석한 성공 사례를 바탕으로 프로젝트를 일정에 맞추는 동시에 고품질을 유지할 수 있는 방법을 소개한다. 1996년 JoltAward 수상작.

[search]프로젝트|10|date|desc|T[/search]

          1.고객이 프로젝트를 설명한것           2.프로젝트담당자가 이해한것      3.분석자가 설계하고 디자인
                                                                                                              한 컨셉



          4.프로그래머가 짠 결과물                  5.테스터가 받은 결과물             6.컨설턴트가 묘사한 결과물


          7. 프로젝트中 문서화된것                8.설치했을때 작동되는 결과              9. 고객이 결과물에 대해
                                                                                                                     지불한 금액의 크기



          10.결과물에대한 유지보수              11.마케팅담당자가 광고했을때        12.실제설치된 시기와 형태


           13.정말로 고객이 원했던것             14.추천사이트에 홍보한 결과        15.이러한 결과로 새계획을
                                                                                                                추진할때



쓴웃음이 나옵니다... 도대체 어디서 부터 잘못된건지.... (그걸 따지는 것 자체가 잘못일까요? ㅡ.ㅡ;;)

IT프로젝트 성공율은 30%도 체 도달하지 못하는 경우가 많습니다.
(CHAOSR보고서를 보면 시간이 지날수록 성공율은 올라가긴 하지만, 30%를 넘지 못하는 경우가 많다고 보고하고 있습니다.)

이런 현상은 프로젝트의 규모가 클수록  (성공률) 더 낮게 나오고 있습니다.




프로젝트 실패의 원인에 대해서 우리는 흔히 인력에 대한 부분이 가장 높다고 생각하는 경우가 많습니다.
인력관리는 프로젝트 성공을 위한 중요한 활동임에 틀림이 없습니다.
투입시기 및 일정, 외주관리, 스킬함양등등 인력활동이 중요한 요건이라고 생각하고 있으며 특히 인력 투입시기와 기술적 요건을 실패를 가져오는 직접적인 요인이라고 말하곤 합니다.

하지만 인력에 의한 프로젝트 실패는 큰 비율을 차지 하지 않습니다. 오히려 팀원보다 Manager의 역량에 의한 실패는 더 큰 이유입니다.


팀원이 제대로 움직이도록 하는 것은 매니저에 있습니다.

팀원의 숫자가 생산성에 비례한다는 것은 잘못된 생각 입니다.

어느 회사의 임원급 사람이 자신의 회사가 가지고 있는 힘은 직원이 많다는 것이라며 공공연하게 말하곤 했습니다. "수행하고 있는 많은 프로젝트중 문제가 발생하면 회사내 가용할 수 있는 인력을 많이 넣어 반드시 수행한다."

얼핏 듣기로는 맞는 말 같지만, 프로젝트 관리라는 차원으로 본다면 얼마나 위험한 생각을 가지고 있는지 금방 알 수 있습니다.
시간은 한정되어 있고, 프로젝트 일정에 따라 또는 팀원의 경험 혹 스킬 부족의 해석으로, 밀어 붙이면 된다는 판단은 어리석은 생각입니다.

일 정이 지연되는 것은 팀원의 스킬이나 경험 부족이 잘못된 것이 아니라, 잘못된 일정계획과 그런 상황에 대한 무감각한 결정권자들의 무능력함이 더 큰 이유일 것입니다. - 물론 팀원의 스킬이나, 경험부족이 원인이 될 수 있을지 모르나, 그런 팀원을 적정하게 배정하지 못하는 매니저의 능력부족이 더 큰 원인인 것입니다. -
일정의 지연은 팀원(능력이 되던 안되던, 경험이나 스킬이 부족하던 탁월하던)에 따란 제대로된 일정 계산과 계획의 문제가 원천적인 이유라고 봐야 할 것입니다.

그래도 아직 매니저는 할 말이 있습니다. 제대로 된 인력만 준다면 문제 없이 프로젝트를 순조롭게 할 수 있다.

로버트 바인더는 오히려 팀의 진화를 말하고 있습니다.



팀원과 기술적 구현은 프로젝트 실패의 큰 원인은 아니다.






freepower님께서 강팀장의 글을 읽고 "인력이 제때 들어오지 않으면 결국 프로젝트에는 큰 위험이 발생하게 되는 것 아닙니까? 그 자체가 인적자원의 문제인것 같습니다" 라는 글을 보내 주셨습니다.

맞습니다. 이 글은 한가지 전제를 두고 있어야 합니다. "회사에서 인력투입을 프로젝트 진행 계획대로 투입을 시켰을때"의 상황을 말하는 것입니다.

넓 은 의미의 프로젝트를 본다면 적절한 인력투입 시기와 투입여부 또한 프로젝트의 인적자원관리라고 볼 수 있습니다만, 더 중요한 것은 투입시기 산출과 투입여부 또한 매니저의 역활중 하나 입니다.  회사가 인력을 투입해 주던 안 해주던 매니저는 그 역활을 위해 최선 다해 활동을 해 주어야하고 그에 따른 책임을 가져야 할 것입니다. 반면 회사는 매니저가 그런 활동을 하도록 매니저로써 권한을 명확히 해야 합니다.



우리는 2가지 고질적인 문제점을 가지고 있습니다.

1. 거의 대부분의 회사에서는 인적자원이 확보 여부와 관계 없이 프로젝트를 진행하고자 한다.
회 사는 간혹 이후 프로젝트를 위한 프로젝트를 하는 경우가 많습니다. 이런 경우는 주로 정치적인 프로젝트가 될 가능성이 높습니다.정치적 프로젝트는 그 자체가 많은 위험요소를 지니고 있는데 그중 가장 고질적인 부분이 최소로 최대한 이라는 생각을 가지고 있다는 것 입니다. 

2. 매니저에게 정확한 권한과 책임이 주어지지 않는다.
프 로젝트를 진행할때 매니저의 역활은 굉장히 중요합니다. 하지만 그에 따른 권한과 책임을 주지 않고 이중적 잣대를 가지고 본다는 것입니다.  간혹 권한은 없고 책임만 묻는 것이 거의 대부분 회사의 행태인 것 같습니다. 전 이 또한 매니저를 관리하는 윗 사람들의 자질에 문제가 있다고 봅니다.

1번째를 어느정도 완화시킬 수 있는 대안은 2번에 있습니다만.... 여전히 회사도 매니저도 할말이 많을 것 같습니다.

그림에 대한 의견보기..






 

얼마전 M회사에 이력서를 제출한 바 있었다.



이력서를 낸뒤 일주일 정도 지나서 면접이 잡혔고, 면접을 봤다.

면접을 진행했던 담당 차장님의 질문이 지금 강팀장의 상황에서 머리속을 떠나지 않고 있다.

Q. 수주를 받은 Project의 일정이 왜 지켜지지 않을까요?
A. Project의 일정은 크게 2가지 원인이 있을 수 있겠습니다.
첫번째 무리한 Project 수주에 있습니다. 무리한 수주는 팀구성과 프로젝트 운영에 대한 부담을 주게 됩니다. 이런 부담은 팀 전체의 사기와도 밀접한 관계가 있고 이에 따른 발주처의 불만족이 여러가지 사고의 원인을 일으키게 됩니다.
두번째 팀원의 구성에 문제가 있습니다. 팀원은 해당 프로젝트에 대한 이해와 경험들이 동반되어야 ISSUE 발생에 대한 원활한 대처가 이뤄질 수 있습니다.

Q. 팀원 구성 문제가 있다고 하셨는데... 구체적으로 어떤 문제가 있다고 보십니까?
A. 개개인적인 문제를 모두 짚을 수는 없습니다만 제 경험을 말씀 드리자면 OOOO프로젝트에서 인력수급이 제대로 되지 않아 처음에 팀원 구성이 되지 않았습니다. 그리고 급하게 팀원을 맞출때 대부분을 프리랜서로 구성하게 되었습니다. 인력수급이 안되어 초기에 팀원들의 프로젝트의 전반적인 Study가 되지 않았고, 뒤에 투입된 프리랜서는 소속 직원 만큼 책임감 있게  프로젝트를 진행하지 못해 일정에 문제가 발생하는 ISSUE가 발생 하였습니다.

Q. 수주 회사의 사정이라는 것이 있을 수도 있지 않습니까?
A. Project에 문제가 생기는 근본적인 이유를 2가지로 말씀 드렸습니다만, 수주회사가 초기 Project 를 수주할때 그 사정을 스스로 정확히 판단하고 평가하여 수주를 받아야 한다고 생각합니다. 물론 이후의 Project를 생각할 수도 있겠지만 근본적으로는 먼저 수주를 받고 보자는 식의 진행은 지금에나 이후에도 회사에 큰 부담과 문제로 자리잡게 될 가능성이 높습니다.
하지만 사정에 의해 프로젝트를 수주 받았다면, 팀구성과 팀원의 구성, 팀운영에 대한 부분은 PM의 자질에 따라 문제를 최소화 시킬수도 있습니다.

.... 이하생략



블로그를 뒤지다 프로그래머에 대한 그림 몇장을 봤다. 비단 프로그래머뿐만 아니라, 디자이너도 기획자도, PM도 마찬가지가 아닐까 생각한다.

Project 수행에 있어서 가장 중요한 것은 역시 사람이다.
팀원간의 관계... 발주자와 수주자의 관계....
하지만 단지 사람과의 관계만으로 이 문제를 다 푼다는 것은 뭔가 빠진듯 하다. 아마 "회사"가 아닐까....??!!



출처 : http://blog.naver.com/imcjpark/10016181044


출처 : http://blog.naver.com/superxt/120035920668

프로젝트 스코프 관리란 프로젝트 성공을 위해 해야 할 일과 하지 말아야 할 일을 판단하여 해야 할 일이 누락되거나 하지 말아야 할 일이 수행되지 않도록 프로젝트 스코프를 계획하고, 정의하며, 실행된 스코프를 검증하고, 승인된 스코프의 변경을 통제하는 활동을 포함한다. 프로젝트 스코프 관리는 프로젝트의 분야나 규모에 관계 없이 반드시 수행해야 하느 가장 기본적이면서도 중요한 업무이다.


스코프 기술서는 스코프 계획 프로세스의 출력물로 장래에 프로젝트와 관련된 결정의 기준이 되는 문서이다.


WBS는 스코프 정의 프로세스의 출력물로 프로젝트를 산출물 중심으로 분할을 반복하여 더 작고 더 관리하기 쉬운 산출물로 만든 체계적인 문서이다.


WBS는 프로젝트 스코프에 대한 성과기준계획으로 반드시 고객과 경영층의 공식적인 승인과정을 거쳐야 한다. 일단 승인된 WBS는 프로젝트 스코프의 성과기준 계획으로서 특정한 업무가 프로젝트 스코프에 속하는지를 판단하는 근거가 된다.


스코프 변경은 합의된 스코프, 즉 승인된 WBS를 변경하는 것으로 작업중단, 프로젝트 계획변경, 재작업 등을 유발하므로 신중히 결정되어야 하며 일단 결정된 변경사항은 신속하고 정확하게 기존 계획에 반영되어야 한다.


프로젝트 관리자는 프로젝트 스코프 관리의 개념과 중요성을 이해하고 WBS의 작성 및 승인 절차에 대한 실무적 지식을 가지고 있어야 한다.



스코프 관리

■ 스코프란 프로젝트의 성공을 위해 수행되어야 하는 일들의 집합이다.

■ 프로젝트의 스코프는 프로젝트 스코프와 프로적트 스코프로 구분된다.

■ 스코프 관리의 기본방향은 스코프 최소화, 스코프 변경 최소화, Gold plating 방지이다.


프로젝트 스코프 관리란 " 프로젝트 안에서 수행되는 업무가 (프로젝트를 성공적으로 완료하기 위해) 꼭 필요한 모든 항목만으로 이루어지도록 보장하기 위한 프로세서"를 포함한다. 스코프 관리의 주된 업무는 프로젝트 실행과정에 꼭 필요한 업무가 빠지거나, 반대로 불필요한 업무가 포함되는 일이 없도록 업무의 범위를 관리하는 것이다.





스코프(Scope)란 "프로젝트를 통해 제공되는 제품과 서비스의 합" 이다.