프로젝트를 어떻게 관리 하느냐는 관리자 혼자 하는것은 아니지만 관리자의 역할의 중요함에 있어서 부인하는 사람은 없을것이다.

분명 프로젝트를 잘 관리했다는 소릴 듣고자 한다면 다양한 방법의 프로젝트 접근 방법이 필요하고 자신만의 접근방법을 만들어내야 한다.
다른사람들의 답습으로 만들어진 관리기법들이 정작 본인에게는 어울리지 않을 수 있기 때문이다.
어떤 이는 범위 산정에 촉각을 곤두 세워 클라이언트와의 협의를 잘하는 사람이 있는가 하면 어떤 이는 일정과 예산별 관리를 잘하는 친구 어떤 이는 고객에게 포커싱을 맞춘 관리방식을 해오곤 한다.
이렇듯 각기 다른 프로젝트의 관리를 방법론으로 만들어 내야 한다. 본인만의 본인에게 어울리는 관리 기법을 찾아 내야 향후 어떤 프로젝트에서도 성공할 수 있다. (단 모든 프로젝트에서 적용이 되진 않으며 일반적인 프로젝트에서의 관리를 말한다.)


개인적으로 하나의 프로젝트를 맡게 되고 이끌어 옴에 있어 세가지의 접근 방법을 추구 한다.

첫번째.
관리 영역 접근방법
핵심관리 영역은 범위와 일정, 원가, 품질에 있다.
적어도 범위만은 꼭 관리 하려고 노력하는 접근 방법이다.
이에 필요한 문서들은 꼼꼼하게 체크 하고 클라이언트가 귀찮아하리만큼 되뇌이구 되뇌인다.
'기술 협상 시 이렇게 하기로 하였습니다', '착수보고 시 협의된 내용입니다', '몇일 몇시에 이렇게 회의 진행 하였습니다'
솔찍히 이런 관리 접근 방법을 좋아 하는사람은 없다.
관리자로써 향후 영업적인 측면에서 본다면 비효울적인 부분도 있기 때문에 품질에 대한 확신이 필요하다.
범위에 대한 부분을 체크를 꼼꼼하게 하고 품질이 떨어진다면 프로젝트의 관리는 1차원적으로 실패한것이다.
적어도 이번 프로젝트는 향후 몇년간 지속적인 관리가 되도록 품질에도 범위의 관리 만큼 신경을 써야 하는것이다.
범위와 품질의 효율적인 적용이야 말로 이번 접근 방법은 효과적인 관리 접근방법이 될것이다.

- 핵심 관리 영역 : 범위, 품질
- 보조 관리 영역 : 일정, 원가, 자원, 위험, 소통, 조달

두번째.
단계별 접근 방법
다양한 프로젝트, 각기 다른 프로젝트 에서도 분명 단계적인 상황은 존재한다.
컨설팅(영업), 착수, 설계, 구현, 테스트, 완료, 유지보수
프로젝트의 성향에 따라서 단계의 빠짐은 있을 수 있지만 거의 이런 단계에 맞게 진행된다고 보겠다.
각 단계내에서도 어떤 형태의 진행을 할것인지 세부 단계로 나누고 그에 대한 일정을 체크 한다면 업무의 진행에 대한 척도를 마련할 수 있다.
또한 이 접근 방법에는 각 단계별 중요도를 %로 나누어 최종 완료 시점까지의 진척도 체크 하는데 유리하여 효과적인 보고도 완료 할 수 가 있다.
그만큼 신뢰도를 쌓을 수 있는 근거가 될 수 있다.
이런 접근 방법에도 분명한것은 진척도만을 따지는것이 아닌 품질에 근거한 진척도를 따져야 한다.

- 핵심 관리 영역 : 일정, 품질
- 보조 관리 영역 : 범위, 원가, 자원, 위험, 소통, 조달

세번째.
고객관점의 접근 방법
프로젝트의 완료의 시점에서 가장 중요한것은 고객의 만족도다.
고객이 만족하지 않은 프로젝트를 어떻게 완료 했다고 검수확인서에 날인을 하겠는가?
100% 완벽한 만족도를 높일 수는 없겠지만 적어도 그들이 부분적으로도 만족 할 수 있는 꺼리들을 만들어 내야 한다.
그리고 그에 대한 고객의 설득력 있는 품질관리도 필요 하다.
고객의 관점에서는 프로젝트 완료일 엄수와 보고자료 제공(클라이언트가 보고 할 수 있도록 문서화 하여 제공한다.), 품질에 대한 기대조건 만족, 요구사항에 대한 협의 완료에 대한 완료다.

- 핵심 관리 영역 : 일정,품질, 요구사항
- 보조 관리 영역 : 범위, 원가, 자원, 위험, 소통, 조달

위의 세가지의 접근 방법은 하나의 접근방법만 사용해서는 안된다 세가지 모두의 접근을 진행 했을때 그 시너지 효과는 배가 된다.
또한 세가지 접근 방법의 근간은 품질에 있다. 품질의 만족이 없으면 프로젝트에서는 실패한것이나 마찬가지다.


Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

  1. 2012.06.08 16:22 신고

    어떤 관점에서 프로젝트를 관리할지를 먼저 정해야 합니다.
    그래야 중요한 시점에서 흔들리지 않는 관리자가 될 수 있습니다.
    그리고 프로젝트의 주요 이슈들을 꼭 작업자들과 공유 해야 합니다. 성공은 항상 기본에서 시작하는것이니까요

마전 어려움을 겪었던 프로젝트에서 다시 한번 신뢰가 프로젝트에서 얼마나 중요한지를 깨닳게되었다.
프로젝트에서 중요한 요소들이 많이 있겠지만 그중에서도 신뢰란 기초가 없을때는 그나머지는 허물어지게 마련인듯 하다.
그러면 믿음이 발생하는 요소들과 대처방안은 어떤것이 있는지 알아보겠다.










프로젝트 진행시 필요한 신뢰의 요소


1. 팀원들과의 신뢰

팀원들과의 신뢰은 프로젝트의 품질을 높이는 방법 중에 하나이다.
아무리 작은일을 진행하는 작업자라 하여도 신뢰가 쌓이지 않으면 그 작업은 수포로 돌아간다.
신뢰를 얻기 위해서는 본인의 위치를 잃지 안도록 하되 낮은 자세로 임해야 함을 잊지 말아야 한다.
목에 깁스를 한 자세로 아래를 보지 못한다면 팀원들은 그 관리자를 믿지 못할것이다.
신뢰는 작은곳에서 온다 본인의 마음가짐에서 신뢰는 쌓이게 된다.

2. 클라이언트와의 신뢰

프로젝트 진행시에 넘어야할 관문이다.
변화무쌍한 클라이언트들을 보면 신뢰를 갖기 힘들다. 이럴땐 성실함을 무기로 쌓아야 한다.
기술적인 대응은 각 중간단계의 관리자와 협의하여 진행하면 되지만 직접 대화하고 제안하는 입장에서 클라이언트의 마음을 읽고 그에 대한 답을 제출해야 신뢰는 쌓이게 된다.
기본적인 신뢰는 제안의 완성도에서 올테지만 프로젝트 기간 중에 서로의 믿음은 관리자의 성실함에서도 점수를 많이 딸수 있다.
성실하게 임하는 자세야 말로 클라이언트가 원하는 관리자의 자세이다.

3. 임원진과의 신뢰

프로젝트이 리소스에 대한 측정을 하는 단계에서는 임원진의 개입될수밖에 없다.
팀간의 리소스를 분산하는 팀장의 입장에서는 프로젝트를 관리하는 관리자에게 어느정도의 신뢰를 믿고 리소스를 분배하게 되는데 이럴때 신뢰가 없을때는 리소스 배분에서도 힘들 뿐 더러 추가적인 지원에 대한 불안한 요소를 만들게 된다. 반대의 경우가 될수도 있겠지만 문제는 신뢰의 바탕이라면 조금더 부드러운 리소스 지원이 가능하기 때문이다.
또한 임원진에게 얻는 신뢰는 단기간에 얻을 수 있는것이 아니여서 계속적인 유지도 필요하다.

4. 자신과의 신뢰

여러가지의 특성의 프로젝트를 진행하게 되면 자신에게 맞는 프로젝트가 나오기 마련이다.
이런 프로젝트는 자신감이 있어 진행하는데 무리가 없지만 처음하는 프로젝트나 자신이 힘들어했던 프로젝트는 자신과의 신뢰가 없어 초기부터 프로젝트를 힘들게 이끌어 갈 수밖에 없는 상황이 온다.
자신에 대한 믿음이야 말로 가장 중요한 프로젝트의 기초다.
자신의 믿음을 얻기 위해서는 계속적인 지식의 습득 밖에는 없는듯 하다.


신뢰의 바탕에서 프로젝트의 운영은 새로운 발견을 하게 된다.
좋은 프로젝트, 즐거운 프로젝트를 운영하기 위해서는 무엇보다도 4가지의 요소를 잊지 말고 진행해야 겠다.
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요


견적의 기본이 되는 S/W기술자 노임단가표 최근버전이다.

전체 증가의 변화도 궁금하여 차트화 하였는데 증가액 만큼의 인력의 대우도 진행되었는지 궁금하다.

대우만큼의 변화는 아니여도 이쪽에 종사하는 분들의 자신의 단가는 알아야 한다.

본인의 위치도 분명하게 알아야 하고 특히 SW기술자 사전 신고제에 대응하는방향도 개인적으로 모색해야할 때이다.

SW 기술자 등급별


2010년도 적용 SW기술자 노임단가 공표

소프트웨어산업진흥법 시행령 제16조(SW기술자의 등급별 노임단가)의 규정에 의한 소프트웨어사업의 대가기준에 적용할 소프트웨어기술자 일 노임단가를 통계법 제23조에 의거 다음과 같이 공표합니다.

【2010년 공표임금: 일 급여 기준】

(단위: 명, 원)

구 분

2010년
조사인원

노임단가

전년대비
증가액

2008년도

2009년도

2010년도

기술사

319

339,988

356,999

358,777

1,778

특급기술자

9,760

300,570

314,773

333,226

18,453

고급기술자

8,071

225,306

228,833

239,085

10,252

중급기술자

9,198

187,566

190,248

188,139

-2,109

초급기술자

11,714

140,198

141,761

146,620

4,859

고급기능사

578

116,845

126,106

140,918

14,812

중급기능사

895

101,158

109,777

110,637

860

초급기능사

990

80,993

86,961

90,599

3,638

자료입력원

1,065

-

67,032

69,680

2,648

* 본 2010년 노임단가는 인원가중평균치임.

* 상기결과는 일급여기준이며, 기본급여+제수당+상여금 등을 모두 포함한 결과임.

* 자료입력원 노임단가의 기본급여는 2009년 48,493원, 2010년 58,795원으로 조사됨.

* 2010년의 월평균 근무일수는 전년도와 동일한 21.6일로 조사됨.

* SW기술자 공인노임단가는 2009년 대비 평균 5.9% 증가함.

<시행일> 2010년 9월 1일부터

2010년 8월 31일

한국소프트웨어산업협회장




참고 :
제경비의 계산방식은 순수 인건비 * 1.1
기술료는 (순수인건비 + 제경비) * 0.2
순수인건비는 노임단가를 참고하시면 되겠구요

Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

프로젝트를 망치는 요인 중에 하나가 커뮤니케이션이라고 많이 얘기한다.
커뮤니케이션의 단절은 프로젝트의 심근경색과 같다.
현재는 모르지만 언젠가 크게 터지게 되는 손도 못쓸정도로 위험한 단계까지 가게 된다.





그럴때 우리는 커피 한잔의 여유가 필요하다.
그리고 모든 작업자들과의 대화가 필요하다.
예전에 어떤 기획자에게 이런말을 했다.
관리자가 되려면 먼저 귀를 파라 그리고 입은 신중하게.
열린 귀와 심사숙고한 말로 커뮤니케이션을 하는것 그것이 가장 필요한 사람이 관리자(PM)이기 때문이다.
이런면에서는 나도 어려움을 느낀다.

말을 자르고 내말을 먼저 하는 경우가 더 많았기 때문이다.
언젠가 그런 경우 느끼게 된다.
내가 느꼈던 것처럼 그때의 잘못들을 느끼게 된다.
그럴때 후회하는것보다 지금 준비 하는것이 현명한 방법일것이다.

PM을 위한 커뮤니케이션의 첫번째 방법은 : ' 귀는 열고 입은 신중하게 '

중요한 사항이 발생 할때 회의를 진행 하게 된다.
각 팀별로 주장이 커질때 그 팀들은 선택권을 PM에게 던져준다.
모든 눈들이 PM에게 몰리게 되고 선택을 기다리게 된다.
그럴때 확실한 답변을 해야 한다. PM은 리스크와 프로젝트의 완료를 생각하여 선택을 해야 한다.
그리고 그 선택에 대해서 각 팀/작업자에게 설명을 해야 한다.
왜 이런 결과가 나왔는지를 커뮤니케이션을 해야 한다.

PM을 위한 커뮤니케이션의 두번째 방법은 : ' 이해 할때까지 자세한 설명을 해라 '

커뮤니케이션할때 짧게 얘기 하는것은 상대방에게 호기심을 늦추게 한다.
길게 얘기해서 커뮤니케이션의 장으로 인도를 해야 한다.
어떠한 방법도 좋다 커뮤니케이션의 장으로 인도해라 그가 누가 되었던지 커뮤니케이션을 함으로써 기적을 만나게 될것이다.
그리고 어느정도 인도가 되었을때는 귀를 열어야 한다.

PM을 위한 커뮤니케이션의 세번째 방법은 : ' 커뮤니케이션을 유도 하라 '

관리란 끝이 없다.
어떤일이 발생할지 모르는 상황에서 많은 작업자들과의 커뮤니케이션은 어려운 프로젝트의 활력소가 될것이다.
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

일정관리는 전체 진척율에대한 근거 자료가 됨으로 프로젝트의 보고 단계에서 가장 중요 하다고 할수 있다.

 

보통 MS-Project 를 많이 사용하며 스크립트를 이용한 목표대비 진척율과 실제 진척율로 나누어 문서화 할수 있다.

MS-Project 는 무료로 제공되는 뷰어가 있어 작성후 관련자들과 문서를 공유하는데 어려움이 없다.
뷰어 다운로드 : http://file.naver.com/pc/view.html?fnum=282171&cat=30


다음으로 많이 사용하는 프로그램으로는 MS-Office의 엑셀이 있다.

마찬가지로 진척율을 체크하기 위해 목표와 수행으로 나누어 진척율을 잡을 수 있다. 다양한 함수를 사용하여 문서의 자동화를 만들수 있으며 뷰어도 제공되어 문서 공유하는데 어려움이 없다.

뷰어 다운로드 : http://file.naver.com/pc/view.html?fnum=235304&cat=30

 


진척율을 체크하는데 중요한체크포인트는 다음과 같다.

 

1. 작업의 프로세스로 Task 를 만들라.

- 어느 누가 보아도 이해하기 쉬운 프로세스로 Task를 잡고 진행율에대한 체크를 한다.

 

2. 작업의 단위(Task)는 최소 단위로 해라.

- 작업자들은 자신의 작업에 대한 상세한 내역을 알 수 없다. 각 작업자들이 진행 될 수 있는 작업에 대한 리스트를 뽑고 그 작업에 대한 협의는 각 작업자들과 진행 해라 그리고 작업자들에게 예상되는 일정을 체크 해달라고 하면 자연스러운 작업 진행이 될 수 있다.  혹시 빠진 Task가 있다면 이후 일정에 추가 하면 된다. 너무 걱정 안해되 된다.

단위별로 나누기 힘들다면 전체 페이지(IA 정의서, 메뉴구조도)를 기준으로 진행하면 된다.

 

3. Task에 각 작업자에 대한 일정을 체크 하고 작업자별 검수와 Task별 검수를 진척도에 포함 시켜라.

- 작업자들이 놓치기 쉬운 부분이 완료 후의 단위 테스트다. 단위테스트는 각 작업자들의 몫이며 각 작업자들이 검수 하는것이 맞다. 완성도를 높이기 위해서는 각 단위별 테스트를 진행 하고 체크 하는것이 중요 하다. 또한 하나의 Task가 완료 되었을때 이에 대한 단위 검수를 진행하여 클라이언트를 작업에 포함 시켜라. (진척율이 올라가지 않는 이유가 클라이언트의 검수 때문임을 보고 한다면 클라이언트는 검수를 진행할 수밖에 없으며 단위 검수가 진행 되면 최종검수는 그대로 넘아가는것.

 

4. Task별 중요도를 체크 하라.

- 작업에 대한 중요도를 체크 하지 않으면 작업자의 리소스에 대한 체크(M/D)밖에 진행되지 않는다. 메인페이지와 서브페이지의 중요도가 다르듯이 각 작업들의 중요도를 체크 하고 중요 분류별 중요도도 체크 하는것이 좋다.

 

5. 주 1회 이상의 진척도를 체크 하라.

- 각 파트별 진척도를 PL에게 요구 하고 PL은 각 작업자들에게 체크 하도록 한다. 분명한것은 자주 하는것보다는 주 1회 또는 2회로 PL을 신임하는것도 중요하다.

 

6. 진척도에 대한 대응방안을 마련하라.

- 목표치를 못미쳤을때의 해결 방안을 마련 하고 그 대응방안은 미루면 안된다 빠른 조치를 취함으로써 도미노현상(하나의 파트의 작업이 완료되지 못할때 다른파트의 작업 진행이 안됨으로써 일어나는 리스크 현상)에 대한 대비를 해야 한다.

 

마지막으로..

일정관리는 무엇보다 작업자들의 목표대비 완료율을 체크 하는데도 중요하다.

이 프로젝트가 마지막이 아니니 각 인력에 대한 목표대비 완료율을 표시하는것이 리소스 관리하는데 필요한 부분이다.

다음 프로젝트에 리소스관리를 하는데 도움이 될것이다.


Posted by 김상환
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

요즘 PM의 역할이 얼마나 중요한지를 세삼 깨닫는 이유 중에 하나가 업무의 역할 분담인듯 하다.

사람이 하는 일이다 보니 작업자들 간의 언쟁과 각팀간의 업무 진행상의 문제점도 생기게 마련이다.

이럴때 가장 중요한것은 각 업무 분장에 대한 작업 진행의 체크 이다.


초기 프로젝트 진행 시 각 작업자들의 배정을 받은 후 작업 진행에 대한 프로젝트관리대장이 필요 하다.


프로젝트 관리 대장에는 다음의 것들이 포함되면 좋은데.


1. 프로젝트 개요 (프로젝트 명, 목적, 간단한 컨셉, 기간, 주요사항... 등의 개요)

2. 수행내역서 (프로젝트의 범위 분석(RFP, 제안서, 기술협상, 착수보고(수행계획서), 요구사항정의서 등의 전체 프로젝트의 범위)

3. 작업자의 조직도 (TFT(Task Force Team)의 모든 작업자의 위치(PM, PL... )를 명확하게 표시)

4. 업무 분장 (상세하게 업무 단위별(Task)로 나누고 각 담당자의 역할 및 담당자의 이름을 명시)

5. 프로젝트 컨셉 정의서

6. 프로젝트 일정표

7. 리스크관리(위험관리)


간단하게 프로젝트 진행 시 필요한 내용들을 정리하여 하나의 문서로 가지고 있다면 이후 히스토리관리 및 프로젝트 완료 후 검수 진행 시에도 명확하게 검수를 받을 수 있을것이다.


이 중에  프로젝트 작업자들간의 업무의 분쟁을 줄일 수 있는 부분이 조직도 및 업무 분장이 되겠다.

업무 분장을 알려줌으로써 서열이 나눠지게 되고 각 작업자의 책임있는 진행이 이뤄지게 되는것이라 하겠다.


Posted by 김상환
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

SLA(service level agreement) 적용

 

요즘 공공기관의 RFP에서 자주보는 단어가 SLA다.

언제부터인지 SLA로 사업의 성공여부를 따지는듯 하다.

SLA를 높게 잡으면 그만큼 사업의 범위가 커질 수밖에 없다.

가능한 SLA범위를 잡는것이 중요하며 이범위는 사업의 전체 성공여부까지 결정할 수 있다.

솔찍히 SLA가 있어 검수단계가 깔끔해지는 경우도 있다.

SLA보고만 지나면 검수는 당연한결과이기 때문이다.

다만 기준치에 못미쳤을때의 대비가 가장 중요하다.

일별, 주별, 월별 기준치 체크를 하여 못미쳤을때의 대비방안도 마련하여 SLA의 기준치를 넘어서야 한다.

 

(예시 : 월별 SLA보고를 통하여 전반적인 서비스의 진척도를 나타낼 수 있다)

예를 들면 유지보수의 프로젝트에서 회원가입수와 PV수를 가지고 체크 하는 SLA의 기준을 잡았다면 유지보수 기간에 SNS의 활용과 각종 이벤트를 이용한 대비 방안을 마련하여 꾸준한SNS 활용(트위터, 블로그, 페이스북..)을 진행 하고 회원가입을 유도하는 다양한 이벤트를 진행 하여 SLA의 수치를 맞출 수 있어야 하는것이다.


Posted by 김상환
Posted by 기획에 대한 짧은 생각 웹디맨
Facebook 댓글

댓글을 달아 주세요

이전버튼 1 이전버튼