프로젝트 이해하기

1. Project

1) Project 개념

‌일반적으로 조직 내 목표 혹은 고객과의 계약상의 목표를 달성하기 위해 한정된 기간과 비용 내에서 정해진 자원을 활용하여 완수하고자 하는 과제 등을 의미한다. 전세계 GDP의 23% 정도가 프로젝트를 통하여 파생되고 있는 것으로 파악된다. (ISO, 2013년 기준) 특히, IT, 제조, 토목, 건설, 플랜트, 조선과 같은 수주업종에서는 R&D, 설계/시공, 제품/시스템 개발 품질향상 등의 목적으로 다향한 형태의 프로젝트가 진행된다.

2) 수주업 개념

고객이 발주한 사업을 타 회사들과의 경쟁을 통해 획득하고 이를 수행하는 business를 영위하는 업종을 의미한다. 간략한 진행 과정은 다음과 같으며, 프로젝트를 따오기 위해 참여하는 부분은 컨설턴트 및 영업 직무, 프로젝트 수행 과정부터 참여하는 부분은 기술 직무이다.

‌사업기획 및 발주 → 제안 → 계약 및 협상 → 프로젝트 수행 과정으로 진행된다.

2. IT Project 결정

‌IT 분야의 Project 결정은 사업 발주 및 제안 프로세스 과정에서 다음 기준을 통해서 참여 결정을 하게 된다.

• 타당성 분석 > 제안평가 > 사업참여 의사결정
  

1) 타당성 분석 (Feasibility study)

1. Why
2. What : 사업범위, 일정 적용기술 예산 등을 분석한 사업 계횟
3. Benefit

2) 제안 평가 (경쟁입찰 방식)

기준	기준 설
평가 주체	- 사기업 : 사업 발주 고객 - 공기업: 제안서를 객관적으로 평가할 수 있는 외부 전문가 등 평가위원
평가 대상	- 기술평가 : 제시된 실행안 (기술), 제안서 → 요약서, 발표 자료 - 가격평가 : 제안 가격 → 제안가 (입찰가)
평가 요소	- 공식적 요소 : 수행방안의 적합성 및 차별성, 가격의 적합성 - 비공식 요소 : 고객, 평가위원의 사업장에 대한 호감도, 친밀도, 관계 등

‌평가대상에 대해 기술, 가격 평가는 보통 7:3 혹 9:1의 비율로 이루어진다. 문제가 생기지 않기 위해서는 기술이 좋은 쪽을 선택해야 되기 때문이다. 단, 저가수주의 이유로 가격이 파격적으로 저렴하여 기술이 떨어지는 사업체임에도 불구하고 선택되기도 한다. (한국 조선업이 중국 조선업에 밀린 이유) 이 경우 문제가 발생할 확률이 높다. 마찬가지로, 공공 프로젝트 진행 시, 부정부패를 막기 위해 외부 전문가를 평가위원으로 하지만, 주로 교수진이 그 역할을 함으로써 (문서만 보고 판단) 실제 사업에 대한 판단이 어려워 기술력이 떨어지는 사업체를 선정하기도 한다. 그러한 이유 때문에 공공 프로젝트가 실패하는 경우가 많다.

3) 사업참여 의사결정

‌사업 참여는 사업 수행 가능 여부, 매출 규모와 이익률, 고객과 전략적 관계 등을 고려하여 결정한다. 경영진의 주요 검토 사항은 다음과 같다.

1. 현실적은 수주확보는 어느 정도인가?
2. 성공적인 수행이 가능한가? (기술, 관리, 위험 검토)
3. 매출규모와 이익율은 어느 정도인가?
4. 고객과의 관계유지를 위해 전략적으로 필요한가?
   

매출 규모와 이익율?

100억 프로젝트 1개가 10억 프로젝트 10개 보다 매출 규모가 크다. 즉, 매출 규모가 큰 프로젝트를 택하는 것이 좋다. IT 업종의 프로젝트 평균 이익율은 ~5% 이다. 이는, 실패율이 높기 때문이다. 삼성 SDS는 이익율이 15% 이상 나오지 않으면 참여하지 않는다.

3. IT Project 유형

유형	설명
Consulting Service(컨설)	- PI : 기업의 중장기 IT 전략 수립 (~5년) - ISP : 단위 IT 사업(프로젝트) 기획
System Integration(시스템 구축)	- 신규 사업, 시스템 개발, 구축 및 통합 - 기반 인프라 시스템 구축 및 고도화
Outsourcing (운영 및 유지보)	- 구축된 시스템의 안정적인 운영 - 시스템 기능, 품질 개선 및 유지보수

1) Consulting Service

컨설팅은 ISP, PI → 연차별 사업계획(예산) → IT사업 발주 과정으로 진행된다. 사실 이는 자회사 내부의 기획 부서가 할 수 있지만, 컨설팅 업체가 진행하는 경우가 다수다. 그 이유는 객관성 담보 및 정치적 목적이다. 내부에서 프로젝트를 위해 조직 개편을 실행하려고 하면 반발과 불협화음이 생겨나기 때문에 외부의 힘을 빌려 수행하는 것이 정치적 목적이다. (전문 컨설턴트 투입 단가는 개발자 단가의 2배 - 20배 차이가 난다.)

유형	설
Process Innovation (PI)	- 프로세스 혁신 - 신규 시스템 구축 목적 - 중장기 사업 계획을 위한 정보화 전략을 수립하는 것이 목적 (~5년)
Information Strategy Planning (ISP)	- 정보전략 계획 - 현재의 프로세스를 개선하는 것이 목적 (~1년)

2) System Integration : SI & SM 비교

SI가 SM에 비해 근무 환경이 힘들다는 생각이 만연하다. 상대적으로 기술적 난이도가 높고, 업무 강도가 높기는 하지만 이직에 있어서 유리한 것과 더불어 각각의 장단점이 있다. 특히 다양한 경험을 고루 가지게 되기 때문에 이직 resume 작성에 있어 훨씬 유리하다.

추가적으로 SE, System Engineer 는 hardware, software 등을 개발하고 유지보수하는 기술직을 의미한다. 보통 유닉스, 리눅스, 윈도우서버 기반에서 작동하는 시스템을 구축하는 사람을 의미하며, 웹프로그래머는 보통 이 직군에 속한다고 보면 된다.

유형	설
System Integration (SI)	- 신규 시스템 (New) - 신기술 적용 및 기존 시스템과의 연계, 통합 - 기술적 난이도 높음 - 업무 강도 높음 - 계속 변경되는 고객
System Management (SM)	- 기존 시스템 (Leacy) - 기존 기술 고도화 및 개선 - SI에 비해 상대적으로 기술적 난이도가 낮음 - 고객 유지

4. IT Project 규모

계약범위를 기간, 예산 내에서 좋은 품질로 만들어 내는 것, 이 모든 것을 충족해야지만 성공하였다고 한다. 전세계 IT 프로젝트의 28%는 중도 하차하며 오직 26% 만이 예산과 기한 내에 완료된다. 차세대 프로젝트의 경우 사실상 성공하지 못한다고 보면 된다.

“미국의 1450개 대기업을 대상으로 조사한 결과 IT 프로젝트의 성공확률은 30% 미만이며 완료된 프로젝트의 50% 이상이 책정된 예산의 189% 이상을지출한다. 특히, 1년 이상 장기 프로젝트의 경우 35% 이상이 계획된 일정의 2배 이상의 기간이 소요되었다.”

규	설
소형 프로젝트	- 수행기간 6개월 이내 프로젝트 - 최대 10억, 20억 - 성공 확률 높음
중형 프로젝트	- 수행기간 12개월 이내 프로젝트 - 최대 50억, 100억
대형 프로젝트	- 수행기간 2년 이상 프로젝트 - 최소 1천억 이상, 한국에서는 8천억 측정 - 차세대 프로젝트 (기존 구축 기반 인프라 및 기술을 갈아 엎는 것) 이에 해당 - 성공 확률 희박

5. IT Project 현실

1) Project 실패

국내 프로젝트 주요 실패요인	퍼센트	해외 프로젝트 주요 실패요인	퍼센트
1. 고객의 잦은 요구 변경 2. 기술, 경험 부족 3. 부정확한 기간, 비용 예측 4. 고객, 현업의 참여 부족 5. 영업 부서의 과욕 6. 고객, 현업과의 인관관계 부실 7. 스케줄 관리 미흡 8. 개발 방법론 부재 9. 개발 환경 미흡 10. 품질관리 부족	21% 20% 20% 12% 9% 7% 4% 3% 3% 2%	1. 불완전한 요구사랑 2. 사용자 참여 부족 3. 자원 부족 4. 비현실적인 기대감 5. 경영층의 지원 부족 6. 요구사항 및 사양의 변경 7. 프로젝트 계획 부족 8. 제품이 더이상 필요치 않음 9. 정보기술관리의 부족 10. 기술부족	13.1% 12.4% 10.6% 9.9% 9.3% 8.7% 8.1% 7.5% 6.2% 4.3%

보통 IT의 영업은 테크니컬 영업이라고 한다. 프로젝트 진행 이전에 고객과 먼저 만나기 때문에 기술적인 측면에 대한 기본적인 지식이 있어야 된다. 하지만, 모두 알지 못하기 때문에 기술 부서와 상의해보고 실현 가능한지 판단하고 알려준다고 한다. 일반적인 기술 부서는 안한다, 못한다, 가져오기만 해봐라 라고 의견을 표출하지만, 회사 이익을 위해 상부의 승일을 받고 충분히 가능하다고 전달한다. 이와 같은 부분이 영업 부서의 과욕에 해당한다.

실패 확률이 높은 이유?

이처럼 IT 프로젝트의 실패 확률이 높은 이유는 IT 프로젝트가 특성 때문이다.

• 프로젝트 진행상황을 가시적으로 정확하게 판단하기 어렵다.
• 투입 인력(개발자) 의존도가 높은 속성을 가진다.
• 초기에 사용자 요구사항을 명확하게 정의하기 어렵다.
• 대부분 일괄게약 형태로 진행하여 초기 정확한 규모 산정이 어렵다.
  

건설업과 달리 실체로 보여지는 부분이 없고 보이는 부분 마저 검증 과정에서 reset 될 수 있다.

기계가 작업을 진행하지 않고 사람이 직접 수행하기 때문에 시간 소요가 높은 점도 있지만, 각자의 수행 능력이 제각각이며 객관적으로 판단하기 어렵다. 따라서 프로젝트 수행 인력의 능력이 일관적이지 못하고 그 능력에 따라 영향을 크게 받는다.

프로젝트는 분석-설계-개발-테스트 과정을 거치게 된다. 보통, 분석 단계에서 사용자( 프로젝트 결과물을 사용하게 될 주체 )의 요구사항을 파악한다. 예를 들어 은행 프로그램을 만든다고 하면, 창구에서 은행업무를 진행하는 직원이 사용자가 된다. 그러나 그들의 요구 사항도 제각각이고 수만명 이다 보니 의견 종합이 힘들다. 특히, 기술을 알지 못하는 사용자와의 충돌이 발생하고, test 과정에서 충돌 발생 시, 분석-설계-개발-테스트 과정을 다시 거쳐야 되기 때문에 시간이 예측한 것 보다 많이 소요된다.

2) Crunch Mode

프로젝트의 마감일을 앞두고 일정을 맞추기 위해 팀원들이 수면, 영양, 사회생활, 위생 문제 등을 포기한 채 고강도 근무체제를 유지하는 방식을 의미한다.

게임 업계를 통해 알려졌지만, 과거 IT 업계 전체에 만연해 있었던 프로젝트 수행방식으로 현재 이를 개선하기 위한 사회적 분위기 조정과 노력이 지속되고 있다. (ex. 주 52시간 근무제도)

3) 동양. 서양 차이

” 서양은 계약 중심의 프로젝트, 동양은 계약+관계 중심의 프로젝트를 수행”

서양의 문화는 사업 목표라는 객체 중심으로 프로젝트를 인식하여 계약을 체결하고 프로젝트 수행 중 발생하는 계약 범위 밖의 요구사항은 귑게 거절할 수 있기 때문에 수행 및 관리가 비교적 용이하다. 단, 동양에서는 초기에 설정한 계약상의 프로젝트 목표도 중요하지만 고객과의 관게 유지가 더 중요하기 때문에 고객의 요구에 따라 목표와 범위가 수시로 변동되어 수행 및 관리가 매우 어렵다.

6. IT Project 관리

‌- 통합관리 : 프로젝트의 다양한 관리 요소들을 적절하게 통합, 조정하기 위하여 필요한 관리 영역

분	단	설
Core Area (목표)	1. 범위 관리	요구사항을 기반으로 과업 범위를 정의하고 실행과정 중 범위변경을 통제
	2. 일정 관리	일정 계획을 수립하고 납기 준수를 위해 일정을 통제
	3. 원가	승인된 프로젝트의 예산 내에서 프로젝트를 완료하도록 원가를 통제
	4. 품질	프로젝트 품질 요구사항을 달성하기 위한 계획 수립 및 통제 수행
Facilitating Are (수단)	5. 자원	조직 및 팀원을 구성하고 자원을 효과적으로 활용 및 관리
	6. 의사소통	의사소통 정보를 적절하게 생성, 취합, 배포 및 관리
	7. 위험	발생 가능한 위험을 식별하여 이를 체게적으로 분석 대응, 통제
	8. 조달	조달을 계획하고 조달업체의 성과를 관리 및 통제
	9. 이해관리	식별된 이해관계자의 기대사항 및 그들이 제시하는 이슈를 관리

7. IT Project 수행 방법론: Agile

‌

과정

sprint 기간을 특정 기간으로 고정하고 절대 바꾸지 않는다.

예를 들어, 2주라는 sprint를 고정으로 해두었을 때, 1-10 기능 개발을 1sprint에서 (분석-설계-개발-테스트-검증)의 과정을 거치고, 11-20 기능 개발은 2sprint에서 동일한 과정을 거친다. Waterfall 방법론과 가장 큰 특징을 중간마다 사용자, 고객이 실행되는 부분을 직접 확인할 수 있다. 만약, 1sprint에서 8까지의 기능만큼만 만들었고 수정 사항이 존재한다면 sprint를 늘이는 것이 아닌 이를 sprint2의 기간으로 넘겨서 우선순위흘 정해 진행한다.

단점 및 현실

Agile 방법론은 고객 지향적, work smart hard 라고도 부른다. 단, 실제 이를 적용하기 힘들고 고객 지향적임에도 불구하고 고객이 좋아하지 않는 방법이다. 왜? 각 sprint 마다 우선순위를 결정하라고 하면서 우선순위에서 밀리는 부분은 하지 않기 때문이다. Waterfall 방법론의 경우는 따로 우선순위를 정하지 않고 다 해결해주기 때문이다. 따라서 실제 프로젝트에서는 (고객이 없는) 회사 내부의 프로젝트에서만 사용한다.‌

개발과 테스트 단계로 진입하면서 일하는 시간, 작업량(time, load)가 많아진다. 따라서 Waterfall 방법론은 중반부터 업무 강도가 높아지지만, Agile 방법론은 이 과정을 여러번 반복함으로써 처음부터 끝까지 업무 강도가 높다고 느낀다. 때문에 work smart 이지만 work hard 라고 말한다.