｢정보시스템연구｣ 제16권 제4호

한국정보시스템학회

2007년 12월, pp. 243～268

프로젝트 위험요인 인식에 관한 비교 연구

- 정보시스템 구현 프로젝트에서 소프트웨어 패키지 적용과 순수 개발하는 경우

* 한국 IBM 소프트웨어 사업부 정보관리팀(주저자), smpark@kr.ibm.com

** 서울벤처정보대학원대학교 교수(교신저자), mschae@suv.ac.kr

박송미*․채명신**

			<목 차>
Ⅰ. 서론 Ⅱ. 문헌 연구 2.1 프로젝트 위험요인들이 프로젝트에 미치는 영향 2.2 프로젝트 종류 및 기업의 특성에 따른 위험요인에 대한 연구 2.3 프로젝트 수행자들 간의 인식의 차이에 따른 프로젝트 위험요인 2.4 정보시스템 구축에 있어서 소프트웨어 패키지 적용과 자체 프로그램개발 방법 비교에 대한 연구 2.5 프로젝트 위험요인 도출 및 우선순위 관련 연구 Ⅲ. 연구방법				3.1 연구 가설 3.2 자료수집 및 측정도구 3.3 자료처리 및 분석 방법 Ⅳ. 실증 분석 4.1 표본의 특성 4.2 측정도구의 신뢰성과 타당성 검증 4.3 가설 검정 4.4 검증 결과 논의 Ⅴ. 결론 5.1 연구의 요약 및 의의 5.2 본 연구의 시사점 및 제한점 참고문헌 영문초록

Ⅰ. 서 론

기업에서의 정보시스템의 역할이 커져감에도 불구하고 IS(Information System) 프로젝트의 실패율은 여전히 높은 편이다. Standish Group의 발표에 의하면 75%의 IT프로젝트가 완료를 하지 못하였다고 조사되었다. 또한 50%의 데이터 웨어하우스 프로젝트가 실패하였고(Watson & Haley, 1997). 80%의 지식 경영 시스템이 구축되지 못한 채 프로젝트가 종료되었다(Tiwana, 2000). IT프로젝트는 평균 90% 이상이 예산을 초과하여 지출하고, 120%의 일정을 지연시킨다고 하였으며 (Keil et al., 2002), 이렇게 실패한 프로젝트 비용의 낭비는 약 750억 달러에 이른다(Johnson, 2000). 기업에서의 IT프로젝트가 점점 대형화, 전문화, 복잡화됨에 따라 프로젝트의 실패를 방지하고 정보시스템을 성공적으로 구현하기 위해서 프로젝트 리스크 관리의 중요성이 대두되고 있다. 프로젝트 리스크 관리를 위해서는 예측되는 프로젝트 위험요인들을 사전에 분석하여, 이를 한두 번의 점검이 아닌 프로젝트 기간 내내 프로세스화 하여 적용하고 관리하는 것이 중요하다. 따라서 프로젝트 리스크 관리를 위해서 먼저 프로젝트의 위험 요인 및 성공요인을 확인하고 정리하는 것이 우선되어야 할 것이다.

정보시스템 프로젝트를 성공적으로 수행하기 위한 중요성이 부각되면서 프로젝트 수행의 위험 요인에 대한 연구는 국내외에서 활발히 진행되어 왔다. 데이터 웨어하우스 프로젝트, CRM 프로젝트, 그리고 금융권 기업의 프로젝트 등 다양한 프로젝트의 종류, 또는 대규모 IT 프로젝트 또는 중소기업의 프로젝트 등 프로젝트 규모에 따른 위험요인에 대한 연구가 수행되었다 (김용원 등, 2005), 또한 발주자와 수주자, 프로젝트 관리자와 수행자 또는 사용자 등 프로젝트를 수행하는 수행자들간의 인식의 차이에 따른 프로젝트 위험요인의 우선순위에 대한 연구(박진석 등, 2004)도 있다. 그리고 프로젝트의 위험요인들이 프로젝트의 성과에 미치는 영향을 다루는 문헌들과 국내의 프로젝트 위험요인들에 대한 도출과 이에 대한 중요도를  재정의한 연구(이석준 등, 2004)도 진행되어 왔다.

	프로젝트 위험요인 인식에 관한 비교 연구

｢정보시스템연구｣ 제16권 제4호, 2007년 12월

하지만 이러한 다양한 연구 가운데에서도 시스템 개발 방식에 따라 위험요인 인식의 차이에 대한 연구는 상당히 미흡한 편이다. 기존 프로젝트에서는 기업들이 COBOL, C, Java등의 개발 언어를 사용하여 현업 사용자의 요구사항에 따라 정보시스템을 개발하던 전통적인 개발 방법에 의해서만 프로젝트를 진행하였다. 그러나 최근에는 ERP, SCM, CRM, BI(Business Intelligence)등의 새로운 기업 솔루션들이 등장하면서 이를 구현하기 위한 소프트웨어 패키지들이 등장하였고, 이를 이용하여 프로젝트를 진행하는 사례도 많이 늘어났다. 기업들은 새로운 정보시스템 구현을 고려할 때 이러한 소프트웨어 패키지를 적용해야 할지, 아니면 자사의 상황을 충분히 반영하여 새로이 개발하여야 할지에 대한 고민하게 되었다, 이를 결정하기 위해 시스템 구축의 효과와 투자비용, 그리고 프로젝트를 성공적으로 진행하기 위한 요소들을 검토하면서 두 가지의 개발 방법론에 대해 비교하였다. ERP, CRM, SCM, BI 등의 기존 솔루션 영역들뿐만 아니라, 기업용 시스템을 제공하고 있는 글로벌 기업들이 MDM(Master Data Management), DQM (Data Quality Management)등의 새로운 솔루션 분야를 창출해내고 있다. 또한 새롭게 대두되고 있는 SOA(Service Oriented Architecture)등의 개념이 등장하면서 기업들의 정보시스템 영역의 범위를 점점 더 넓혀 나가고 있다. 이에 따라 새로운 정보시스템의 솔루션 분야를 위한 소프트웨어 패키지가 지속적으로 개발하여 제공되고 있으므로, 이들 소프트웨어 패키지를 적용하는 방안과 순수 프로그램 개발로 프로젝트를 진행하는 방법론의 선택에 있어 기업들의 고민은 현재뿐만 아니라 향후 새롭게 확장되고 있는 정보시스템 분야에서도 지속될 것으로 보인다. 기존 문헌들에서 프로젝트의 종류 및 규모, 그리고 수행자들 간의 인식 등 프로젝트의 다양한 구성 요소들에 따라 위험요인에 대한 차이를 보였던 것처럼 정보시스템 구축에 있어서 소프트웨어 패키지를 적용하는 경우와 기업이 자체적으로 개발하는 경우 중요시될 위험요인에 차이가 있을 것으로 기대된다.

따라서 본 연구의 목적은 기존 문헌들에서 연구된 기업의 정보시스템 구축 프로젝트의 위험요인들을 도출하고, 이들을 순수 개발 프로젝트와 소프트웨어 패키지를 적용하는 프로젝트의 경우로 나누어 비교 연구하고자 한다. 이는 기업들이 정보시스템 프로젝트를 준비할 때 프로젝트의 구현 방법에 따라 프로젝트의 위험요인들을 보다 신뢰성 있게 점검할 수 있도록 도움을 줄 것으로 믿는다.

이를 위해 다음 장에서는 기존에 수행된 프로젝트 위험요인과 관련된 국내외 문헌들을 고찰하였으며, 이 결과를 취합하여 설문문항의 기초가 될 프로젝트 위험요인들을 도출하여 분류하였다. 또한 시스템 자체개발 및 소프트웨어 개발방식의 차이에 대한 선행연구들을 고찰하였다. 3장에서는 연구방법론에 대해 설명하였으며, 본 연구는 IT 컨설턴트들을 대상으로 설문 조사하였다. 4장에서는 실증분석과 그에 따른 논의를 진행하였고, 마지막 장에서 본 연구의 시사점 및 제한점을 제시하였다.

Ⅱ. 문헌연구

2.1 프로젝트 위험요인들이 프로젝트에 미치는 영향

프로젝트 위험요인들이 실제로 프로젝트의 성과에 미치는 영향에 대해서 많은 연구들이 진행되어 왔다. 프로젝트의 실패를 줄이고, 성과를 높이기 위해 프로젝트의 위험을 미리 파악하고 대처하여 방안을 마련하여야 한다. 그리고 기존의 프로젝트 관리 활동뿐 아니라 실질적으로 프로젝트에 영향을 미치는 조직과 고객과 같은 인적 관리 측면도 함께 고려하여야 한다. 이러한 맥락에서 프로젝트의 결과만을 중심으로 성과를 평가하는 것이 아니라 프로젝트가 수행되는 과정상의 프로세스 평가를 통해 프로젝트의 성과를 측정하여야 한다는 논의가 활발하게 이루어졌다 (서창교 등, 2003).

한편 프로젝트의 각 위험요인들이 프로젝트성과에 미치는 영향을 좀 더 구체적으로 정의되어 연구되었다. 김경내(2000)는 프로젝트의 기간, 비용, 품질의 각 요소에 미치는 영향에 대하여 분석한 결과 각 요소마다 발생빈도가 높은 위험요인과 발생빈도는 낮으나 프로젝트의 성공에 미치는 영향도가 매우 높은 위험요인으로 구분하였다. 또한 대부분의 개발업체들이 체계적인 관리 Tool을 통한 프로젝트 위험관리를 하고 있지 못하고 있으며, 프로젝트를 종료할 때까지 모든 계획과 실적, 산출물 등의 체계적인 작성, 관리만이 이를 해결할 수 있을 것이라는 의견을 제시하기도 하였다. 또한 이러한 위험요인들이 프로젝트의 성과뿐 아니라 프로젝트의 Escalation과 De-escalation에 미치는 영향도를 알아보고, 사람들이 인지하는 중요도가 있는지 그리고 이 위험인지가 신구개발, 운영유지보수, 솔루션 패키지 적용개발 등의 프로젝트의 영역별로 차이가 있는지에 대해서도 연구되었다(오수진, 2002)

요구사항의 불확실성이나 사용자 참여부족 등 중요한 프로젝트 위험요인들이 프로젝트 성과에 미치는 영향에 대한 연구도 수행되었다. 정경호(2003)는 사용자의 참여와 정보시스템 개발 프로젝트 상의 요구사항 불확실성이 정보시스템 개발 프로젝트의 성과에 미치는 효과에 대한 분석결과를 제시하였다. 또한 김태준(2004)은 정보시스템 프로젝트를 공공부문과 민간부문으로 나누어 요구사항의 불확실성과 사용자 참여, 개발자 능력 요인이 각각의 정보시스템 프로젝트의 성과에 어떠한 영향을 주는가에 대한 비교연구 결과를 제시하기도 하였다. 이렇게 다양한 위험요인들이 프로젝트에 미치는 영향에 대한 문헌들이 있었으며, 이러한 위험요인들은 프로젝트의 종류나 환경에 따라서도 다른 영향을 미칠 수 있는데, 이에 대한 문헌들은 다음절에서 검토하였다.

2.2 프로젝트 종류 및 기업의 특성에 따른 위험요인에 대한 연구

오늘날 기업의 비즈니스 환경이 다양해지고 복잡해짐에 따라 이를 지원하는 정보시스템의 종류와 범위, 규모가 다양해지고 있다. 단순히 기존의 정보시스템과 같이 업무 프로세스를 지원하는 기간계 시스템뿐 아니라 이들 시스템에서 생성되는 정보들을 활용하여 비즈니스의 신속한 의사결정과 고객관리 등에 활용하는 데이터 웨어하우스나CRM 시스템 등의 정보계 시스템들의 등장으로 여러 종류의 정보시스템 프로젝트들이 활발히 진행되고 있으며, 이들 프로젝트의 종류에 따라 그 위험요인들을 도출해 내고 이들이 프로젝트에 미치는 영향을 알아보는 연구들이 진행되었다. 김용원(2005)은 기존 정보시스템 및 데이터  웨어하우스의 실패요인을 바탕으로 고객, 요구사항, 범위, 프로젝트 관리, 및 기술의 5가지 영역에서 20가지 요인들을 도출하여 체크리스트를 만들었다. 이를 바탕으로 PMI의 확률평가법과 AHP를 이용하여 업무처리 시스템과 데이터 웨어하우스 시스템 프로젝트에 미치는 위험요소들 간에 유의적으로 차이가 남을 증명하여, 두 프로젝트 간에 위험요인의 차별성을 검증하였다. 한경선(2001)은 CRM 프로젝트 관련 연구에서 전문가들을 통해 CRM 프로젝트에 영향을 미치는 위험요인이 무엇인가를 조사하고, 분석적 계층 기법을 이용하여 전문가들이 인지하는 위험요인의 상대적 중요도를 파악하였다.

또한 각 기업의 산업적인 특성에 따른 프로젝트의 위험요인에 대한 연구도 진행되었다. 특히 금융 산업의 경우, 복잡하고 다양한 산업적인 업무 특성으로 인해 정보시스템 프로젝트들이 보다 활발히 진행되어 왔다, 윤영준(2005)의 경우 금융산업 프로젝트에서 위험요인들의 리스트를 도출하여 기존의 프로젝트 위험요인들과 통합한 후 위험요인들의 우선순위를 적용하여 금융산업에 적합한 위험요인 리스트를     재정의하였다, 그 결과 44개의 위험요인들이 금융산업의 정보시스템 프로젝트에서 고려되어야 할 위험요인들로 도출되었다. 그리고 본 연구결과 금융기관의 위험요인 우선순위가 다른 산업의 정보 시스템 프로젝트와 차이가 있음이 조사되었다.

또한 프로젝트의 규모에 따라서도 위험요인 또는 프로젝트에 미치는 영향에 대한 연구들이 진행되었다. 예를 들면 대규모의 IT 프로젝트에서 위험 요인에 대한 연구(Leslie and Catherine, 1994)와 중소기업들을 대상으로 하는 IT 프로젝트의 효과와 비용, 그리고 위험요인들에 대한 연구(Peter et al, 2005)등을 들 수 있다. Peter et al(2005)은 정보시스템 프로젝트의 경험이 적은 중소기업들이 프로젝트를 시작하기 전에 충분히 고려하여 프로젝트의 리스크에 대비함으로써 프로젝트를 성공적으로 진행할 수 있는 유용한 정보를 제공하였다. 이렇게 기존 연구들을 통해 프로젝트의 종류나 규모에 따라 위험요인에 대한 인식이 다르다는 것을 알 수 있었다. 이어지는 다음절에서는 프로젝트에 참여하는 수행자들간에도 인식의 차이가 있는지에 대한 기존 문헌들에 대해 검토해 보았다.

2.3 프로젝트 수행자들간의 인식의 차이에 따른 프로젝트 위험요인

정보시스템 프로젝트를 진행하는데 있어서 프로젝트 관리자, 개발자, 프로젝트 수행원 등 프로젝트 내에서 역할을 담당하는 프로젝트 수행자들과 프로젝트를 발주하는 사용자 및 시스템 부서의 직원들 등 프로젝트 관련자들간 인식의 차이에 따른 위험요인에 대한 연구도 많이 진행되었다.

프로젝트의 사용자와 관리자간에 프로젝트 위험요인에 대한 인식의 차이가 있음이 기존 연구에 제시되어 있다. Keil et al.(2002)은 전문가들을 통한 Delphi기법을 이용하여, 사용자 그룹에서 선택한 13개 위험요인들 중에서 7개만이 프로젝트 관리자 그룹에서 중요하게 선정하였으며, 프로젝트 관리자 그룹에서 중요하게 생각하는 상위 5개의 요인들 중에서 4개는 사용자 그룹에서는 중요하지 않는 것으로 나타났다. 따라서 프로젝트 관리자와 사용자 그룹은 프로젝트 위험 요인에 대해 다른 시각을 가지고 있음을 시사하였다.

또한 기존 연구를 통해서 프로젝트 관리자와 프로젝트 수행자 (컨설턴트, 개발자)간에도 프로젝트 위험 요인을 다르게 인식함을 알 수 있었다. 조숙진 등(2005)의 연구결과에 따르면 프로젝트를 수행하는 수행자 관점에서는 잘못된 개발 전략과 외부 사용자에 대한 고려 미비가 그들의 업무와 밀접하게 관련되어 있으므로 중요하게 인식되었다. 반면, 프로젝트의 전체 일정 및 범위를 통제하고 고객과의 협의를 주 업무로 하는 프로젝트 관리자의 관점에서는 이와 같은 요인들보다 고객의 요구에 대한 응답 지연등과 같은 요인을 보다 중요하게 인식하고 있는 것으로 조사되었다.

또한 금융산업 프로젝트의 통합 위험요인 리스트를 도출한 윤영준(2005)의 문헌에서도 이들 리스트들에 대해 프로젝트 관리자와 수행원들 간의 인식, 그리고 SI 개발업체 개발자와 금융기관 개발자간의 인식의 차이에 대해 연구하였다. 그 결과를 보면, 프로젝트 관리자와 수행원들 간에 인식에 차이가 있으며, 금융기관과 SI 개발업체 개발자간의 인식에도 큰 차이가 있는 것으로 밝혀져 프로젝트 인력들 간의 인식의 차이를 입증하였다.

프로젝트와 관련한 이해관계자 중 또 하나의 중요한 기준이 되는 것이 바로 실제로 정보 시스템을 사용할 현업 인력과 이를 유지하고 관리할 전산인력이다. 기존 문헌을 통해 이들 그룹 간에도 프로젝트 위험요인을 인지하는 인식의 차이가 있음을 알 수 있다. 박정선(2004)의 연구에서는 전산 인력들이 사용자의 능동적인 참여부족을 중요한 위험요인으로 인식하는 반면, 현업 인력들은 프로젝트 단계들의 불명확한 순차관계, 부정확한 프로젝트의 수립이나 미수립, 잘못된 개발 전략 등을 중요한 위험요인으로 인식하고 있음을 보여준다.

이와 같이 프로젝트의 다양한 참여 인력 그룹간에도 인식의 차이가 있으므로, 이를 극복하기 위한 방법 또한 활발히 논의되고 연구되었는데, 이를 위해 프로젝트에서 발주자(고객)와 수주자(SI)간의 의사소통의 중요성이 많이 강조되었다(박진석, 2004). 한편 오히려 이러한 그룹 간 인식의 차이를 프로젝트를 관리하는데 있어 적절히 활용하면 위험요인을 통제하는 데 기여할 수 있으며, 또한 프로젝트 수행 초기단계부터 시작하여 지속적으로 위험요인을 관리한다면 정보화 프로젝트의 실패율을 현저히 낮출 수 있을 것이라는 의견이 제시되었다(박정선, 2004). 이렇게 프로젝트에 참여하는 수행자들 간에도 프로젝트 위험요인에 대해 다양한 인식의 차이가 있다는 것을 알 수 있다. 다음 절에서는 본 연구의 주요 관점인 소프트웨어 패키지 적용과 자체 프로그램 개발 방법의 프로젝트 개발 방법론에 대한 연구에 대해 정리하였다.

2.4 정보시스템 구축에 있어서 소프트웨어 패키지 적용과 자체 프로그램 개발 방법 비교에 대한 연구

급속한 컴퓨터의 보급에 의해 소프트웨어의 수요 또한 폭발적으로 증가되었으나 소프트웨어의 공급을 위한 생산성은 아직 낮은 수준이다. 이를 보강하기 위해 80년대 중반부터 기업들은 자체개발에 의한 소프트웨어 확보의 비중을 점점 줄여나가고 있으며, 패키지 도입에 의한 소프트웨어 확보를 크게 증가시키고 있다(한국 정보산업 연합회 소프트웨어조달 실태조사, 1988). 새롭게 대두되고 있는 소프트웨어 확보 방법들 중에서 범용 패키지 구입에 의한 방법은 매우 주목할 만 하다. 이는 조직의 입장에서 저렴한 비용과 짧은 시간 안에 기업이 필요로 하는 소프트웨어를 확보할 수 있게 하며, 사회 전체적으로는 같은 내용의 소프트웨어에 대한 중복 투자를 하지 않아도 되므로 매우 효율적이다(신현식, 1990). 또한 김길조(1988)는 인적, 물적 자원의 제약을 많이 받고 있는 우리나라 중소기업의 전산화를 활성화하기 위해서는 소프트웨어 확보의 방법이 자체 개발에서 범용 소프트웨어 패키지의 구입방법으로 전환되어야 한다고 주장하기도 하였다. 이렇게 소프트웨어 패키지의 도입이 급속히 진행된 이유를 들어보면, 시스템 설치 및 이용이 짧은 시간 안에 이루어질 수 있다는 점과, 자체 개발에 비하여 가격이 싸고, 또한 소프트웨어나 하드웨어에 대한 전문적 지식이 없어도 될 뿐 아니라, 소프트웨어의 기능, 성능 및 안정성 등에 대한 불확실성이 적다는 점등을 들 수 있다(신현식, 1990). 소프트웨어 패키지를 적용하는 경우 단순히 개발을 하는 경우에 비해 시간, 가격, 그리고 품질 측면에서 정보 시스템 구축시 장점을 제공하는 것으로 유추해 볼 수 있다. 신현식(1990)은 소프트웨어 패키지의 질, 설치작업의 질, 구입과정의 내용 충실성, 그리고 조직 특성 및 부서 특성들을 고려한 구입과정과 관련된 상황 변수들이 소프트웨어 패키지를 설치한 후 기업의 정보시스템 품질 및 성공과 연관성이 있음을 증명하였다. 그리고 양질의 패키지를 도입한 경우 도입한 패키지의 설치 작업을 충분한 계획 및 준비에 바탕하여 신중하게 수행하면 패키지 도입으로 인하여 얻게 되는 효과를 극대화 시킬 수 있다고 하였다. 반면, 패키지 도입의 가장 문제가 되는 것은 그 기업의 업무 프로세스에 맞게 패키지의 기능을 수정하는 데에 필요한 시간과 비용의 불확실성, 시스템 공급자와 관련된 불확실성, 사용자 부서의 요구와 패키지의 기능 모두가 정확하게 파악되기 힘들다는 점 등을 들 수 있다(Lynch, 1984). 따라서 소프트웨어 패키지로 프로젝트를 진행할 때 충분한 계획과 준비, 그리고 프로젝트 리스크에 대비하는 것이 정보 시스템의 구축 효과를 극대화 시킬 수 있을 것이다.

위에 언급된 정보산업 연합회의 조사 결과와 같이 예전에는 기업들이 정보시스템 구축 시 대부분 프로그램 언어를 이용하여 개발하는 프로젝트를 진행하였으나, 이제 점점 기존에 이미 개발되어 활용되어 온 소프트웨어 패키지를 도입하여 활용하는 경우가 늘어나고 있다. 또한, 앞 절의 문헌 연구에서 살펴 본 바와 같이 프로젝트의 종류나 규모에 따라 또는 프로젝트 수행자들 간에 프로젝트 위험요인의 인식의 차이가 있음이 연구되었으므로, 프로그램 언어로 개발하는 경우와 패키지를 도입하는 경우에도 역시 그 인식의 차이가 있을 것으로 판단된다. 이는 이미 기존 문헌에서 이에 대한 연구의 필요성이 제기되기도 하였다(박정선, 2004). 본 논문에서는 이러한 두 가지 개발 방법론의 차이를 정보시스템 프로젝트 위험요인과 접목시켜 소프트웨어를 개발하는 경우와 패키지를 적용하는 경우, 정보시스템 구축 프로젝트 위험요인에 대한 인식의 차이에 대해 연구하는 것이 매우 중요한 의의가 있을 것으로 판단된다.

2.5 프로젝트 위험요인 도출 및 우선순위 관련 연구

IS프로젝트 위험요인에 대한 그룹 간 인식의 차이를 밝히기 위해서는 위험요인을 파악하는 것이 필요한데, 이는 기존 연구에서 활발하게 논의되고 있다. Schmidt et al.(2001), Barki et al.(2001), Boehm(1989), Moynihan(1997), Jiang et al.(2002)등이 프로젝트의 위험요인에 대한 선행 연구를 활발히 진행하여 왔으며, 실제로 정보시스템 프로젝트 진행시 고려해야 될 위험요인들을 제시하였다. 하지만 이들 위험요인들이 한국에서는 국내의 프로젝트 상황과 프로젝트 수행자들의 경험을 바탕으로 다시 정의되고 고려되어야 할 필요가 있었다. 김혜정(2002)은 Schmidt et al.(2001)과 Barki et al.(2001)등의 기존 연구들이 제시한 위험요인 리스트들을 통합하여 최종적으로 14개 영역과 63개 위험요인을  도출한 후, 국내의 정보시스템 구축 전문가 집단을 대상으로 한 설문 및 인터뷰를 실시하여 국내 상황에 맞는 정보 시스템 프로젝트의 위험요인을 새롭게 도출하였다, 또한 Schmidt et al.(2001)과 국내 연구 결과와의 차이점을 제시하고, 프로젝트 관리에서 실패의 유형을 일정, 비용, 그리고 품질로 구분하여 위험관리를 수행하는 것이 좋다는 의견을 제시하였다. 이석준 등(2004)은 이와 유사하게 외국 저자들의 연구 결과를 근간으로 하여 국내 프로젝트 경력이 있는 컨설턴트와 학계 전문가들의 토의를 거쳐 위험요인들을 통합하고 재정의하는 작업을 진행함으로써, 국내의 문화적, 환경적 요인을 반영하여 국내 프로젝트 관리자들이 인식하는 위험요인 54개를 도출하였다. 조숙진 등(2006)은 이석준 등(2004)이 제시한 54개의 위험요인으로 설문을 진행한 후 요인분석 과정에서 총 46개의 위험요인들을 추출하였다. 이러한 일련의 연구들은 국내와 해외의  정보시스템 프로젝트 위험요인에 대한 인식비교를 가능하게 했다는데 중요한 의미가 있다고 할 수 있다. 이와 같은 프로젝트 위험요인 도출을 위헤 기존 문헌에서 제시된 위험요인들을 <표 1>에 정리하여 본 연구의 설문조사를 위한 위험요인들을 정리하는데 활용하였다.

<표 1> 설문대상 위험요인

(1: Schmidt et al.(2001), 2:  Barki et al.(2001), 3: Boehm(1989), 4: Moynihan(1997), 5: Peter et al(2005), 6: 김혜정 등 (2002), 7: 이석준 등(2004), 8: 조숙진 등, (2006), 9: 박정선 (2004))

위험요인 유형	설문 대상 위험요인	1	2	3	4	5	6	7	8	9
1. 프로젝트 관리	1-1. 위험관리 활동의 부족	O					O	O	O	O
	1-2. 프로젝트 관리자의 효과적인 프로젝트 관리기술 부족	O					O	O	O	O
	1-3. 잘못된 개발 전략	O	O				O	O	O	O
	1-4. 효과적인 프로젝트 관리 방법론 부재	O					O	O	O	O
	1-5. 복수의 벤더로 인한 통합의 복잡화	O	O	O	O		O	O	O	O
	1-6. 외부 컨설턴트와 벤더들의 불충분한 역할과 책임 수행	O	O	O			O	O	O	O
	1-7. 변화 관리	O	O				O
2. 사용자 요구사항 관리 및 비즈니스 프로세스와 의 일치	2-1. 잘못된 요구사항 정의	O	O	O	O		O	O	O	O
	2-2. 고객 요구사항의 변화	O		O			O	O
	2-3. 산출물에 대한 고객의 과도한 기대	O						O
	2-4. 외부 사용자에 대한 고려 미비		O					O	O	O
	2-5. 업무보다는 기술을 우선적으로 고려	O		O	O			O	O	O
	2-6. 기업 문화와 시스템에 필요한 비즈니스 프로세스 변화간의 불일치	O					O	O
3. 프로젝트 일정 및 계획	3-1. 과도한 프로젝트 범위		O				O	O	O	O
	3-2. 잘못 정의된 범위/목적	O					O	O	O	O
	3-3. 부적합한 계획 수립 혹은 미수립	O	O				O	O	O	O
	3-4. 프로젝트 초기에 신중히 고려하지 않은 프로젝트 일정		O				O	O	O	O
	3-5. 인위적으로 조정된 일정	O		O	O		O	O	O	O
	3-6. 프로젝트에 대한 공수 부족		O				O	O	O	O
	3-7. 프로젝트 단계들의 불명확한 순차관계		O				O	O	O	O
	3-8. 프로젝트 각각의 활동결과에 대한 예측의 어려움		O				O	O	O	O
	3-9. 시스템 관리직원을 위한 기술 전수 및 교육					O
4. 프로젝트 인력구성	4-1. 프로젝트 인력의 기술, 업무지식, 경험의 부족		O			O	O	O	O	O
	4-2. 프로젝트 진행중의 주요한 인력 손실	O	O				O	O	O	O
	4-3. 부족하거나 과도한 수의 프로젝트 인원	O	O	O			O	O	O	O
	4-4. 프로젝트에 적합한 기술,지식,경험을 갖추지 못한 고객측 인원					O	O	O	O	O
	4-5. 사용자측 대표자들의 프로젝트에 적합한 경험 부족	O	O				O	O	O	O
5. 사용자관리 및 참여의식	5-1. 프로젝트에 대한 발주 담당자의 책임감, 주인의식 부족	O	O				O	O	O	O
	5-2. 사용자의 능동적인 참여 부족	O						O	O	O
	5-3. 정보시스템 도입으로 발생하는 변화를 거부하는 태도		O			O	O	O	O	O
	5-4. 구축되는 정보시스템 목적에 대한 사용자 이해 부족						O	O	O	O
	5-5. 외부 컨설턴트에 대한 과도한 의존으로 내부 인력의 불충분한 참여	O					O	O	O	O
	5-6. 도입되는 정보시스템의 활용성에 대한 부정적 태도		O				O	O	O	O
6. 프로젝트 관련 조직 관리	6-1. 프로젝트 팀과의 고객 각각의 역할과 책임에 대한 잘못된 정의	O	O		O		O	O	O	O
	6-2. 고객의 컨설턴트, 벤더, 하위 계약자 전체에 대한 통제 부족	O					O	O	O	O
	6-3. 사용자 부서간의 마찰	O	O				O	O
	6-4. 프로젝트와 관련된 모든 이해 관계자들을 규명하는데 실패	O					O	O	O	O
	6-5. 프로젝트 팀과 이해관계자들과의 복합적인 관계(다수의 이해관계자)	O					O	O	O	O
	6-6. 프로젝트 진행에 대한 팀 외부 (조직)의 지원 부족		O				O	O
7. 프로젝트의 공식적인 Sponsorship	7-1. 최고 경영진의 프로젝트에 대한 지원 부족	O	O		O		O	O	O	O
	7-2. 최고 경영진과의 관계관리의 부족		O				O	O	O	O
	7-3. 경영진, 프로젝트 Owner의 변화	O					O	O	O	O
	7-4. 프로젝트의 대한 공식적인 승인 획득 실패	O					O	O
8. 프로젝트 팀 내/외의 원활한 의사소통	8-1. 고객과 프로젝트 팀과의 중간 역할 부재		O				O	O	O	O
	8-2. 프로젝트 팀원간의 정보 공유 부족		O					O	O	O
	8-3 개발팀의 요구에 대한 응답의 지연		O				O	O	O	O
	8-4. 프로젝트 팀원과 사용자간의 의견 충돌		O				O	O	O	O
	8-5. 프로젝트 팀원간의 의견 충돌	O	O				O	O	O	O
9. 기술적인 이슈	9-1. 시스템의 유연성(기존 시스템과의 연계 및 확장성) 부족	O					O	O	O	O
	9-2. 검증되지 않은 새로운 기술의 사용	O	O	O	O		O	O	O	O
	9-3. 기술적으로 복잡한 프로젝트		O				O	O	O	O
	9-4. 프로젝트 진행을 위한 기존 시스템 인프라와 자원의 부족					O
10. 프로젝트 외부의 환경적인 요인	10-1. 프로젝트를 불안정하게 만드는 기업 환경의 변화	O					O	O
	10-2. 비즈니스 환경 변화에 의한 범위/목적의 변화	O					O	O	O	O
	10-3. 더 높은 우선권을 가진 프로젝트의 선점으로 인한 일정 충돌	O					O	O	O	O
	10-4. 정치적인 이유 등으로 실패하도록 의도된 프로젝트	O					O	O
11. 비용	11-1. 프로젝트에 대한 잘못된 예산 책정	O	O	O	O		O	O	O	O
	11-2. 유지보수 및 교육을 고려하지 않은 비용 산정	O				O	O

Ⅲ. 연구방법

3.1 연구 가설

기존 문헌에서 고찰된 바와 같이 프로젝트의 종류, 규모, 산업 등의 특성, 프로젝트 참여 인력의 역할, 그리고 국내외 프로젝트 환경에 따라 프로젝트의 위험요인 인식에 차이가 있음을 알 수 있다. 이를 배경으로 실제로 프로젝트 수행 시에 소프트웨어 패키지를 적용하느냐 또는 프로그램 언어로 개발하느냐 하는 프로젝트 개발 방법론에 따라서 프로젝트 리스크에 대비하기 위해 고려해야 할 위험요인들이 다를 것으로 판단된다. 이 두 가지 개발 방법의 위험요인 인식 비교에 대한 필요성이 연구자들 사이에서 제기되기도 하였다 (박정선, 2004).

문헌연구에서 제시된 바와 같이 과거에는 정보시스템 개발을 위해 COBOL, C, Java와 같은 프로그램 언어를 이용하여 사용자의 요건에 따라 시스템 개발을 진행하였으나, 최근에 ERP, CRM, SEM (Strategic Enterprise Management)등의 솔루션 영역이 등장하면서 기업들이 전문 솔루션 패키지를 이용하여 정보시스템 구축 프로젝트를 진행하는 것에 대하여 많이 고려하고 있다. 그리고 일반적으로 이러한 시스템 개발 방법에 따라 프로젝트 진행에 서로 다른 영향을 준다. 프로그램 언어를 이용하여 개발하는 경우는 사용자의 요건에 따라 원하는 방향으로 시스템을 개발하게 되므로 융통성있는 시스템 개발이 가능하다. 반면, 솔루션 패키지를 이용하여 정보시스템 개발을 진행하는 경우는 그 솔루션이 제시하는 전문성을 참조하고 선진사례에서 제시한 업무 템플릿을 활용할 수 있는 반면, 사용자의 요건을 그대로 반영하기가 어려운 특징이 있다. 따라서 이러한 특징들을 고려할 때 이 두 가지 개발 방법론은 프로젝트의 위험요인에 서로 다른 영향을 미칠 것으로 판단되므로, 다음 두 가지의 가설을 검정하고자 한다.

가설1: IT 프로젝트에서 개발방식에 따라 프로젝트 참여자들이 인식하는 위험요인의 중요도에 차이가 있을 것이다.

가설2: IT 프로젝트에서 개발방식에 따라 각 위험 요인 별로 프로젝트 참여자들간 인식의 차이가 있을 것이다.

3.2 자료수집 및 측정도구

3.2.1 자료수집 절차

국내에서 SI 프로젝트를 수행하는 10여개 이상의 기업과 프로젝트 발주의 경험을 가진 기업의 직원을 대상으로 약 150여개의 설문을 e-Mail로 발송하였다. 이중 102개의 설문을 받았으며, 그 중 시스템 자체 개발 및 패키지 도입 모두에 경험이 있는 응답자의 의견만 선택하였다. 결국 답변 2개를 제외하고 100개의 유의한 설문을 분석하여 그 결과를 정리하였다.

3.2.2 측정도구

기존 문헌의 위험요인들을 기초로 하여 위험요인을 도출하였으며, 이를 기반으로 설문지를 작성하였다. 설문지는 도출된 59개의 프로젝트 위험요인들에 대해 개발언어를 사용하는 경우와 소프트웨어 패키지를 사용하는 경우, 두 가지 방법론에 대해 프로젝트 리스크에 미치는 영향에 대한 인식을 묻는 총 118개의 문항으로 구성되었다. 그러나 만일 응답자가 개발과 패키지 중 한 종류의 프로젝트에만 경험이 있는 경우에는 경험이 있는 59개 설문 항목들만 그 대상이 되었다. 7점 척도에 기반한 설문지의 자세한 설문내용 구성은 < 표 2 >와 같다.

<표 2> 설문의 구성

	위험요인 카테고리	세부 문항
개발 언어를 사용하여 개발 프로젝트 수행시	1.프로젝트 관리	총 8문항 (1-1 ~ 1-8)
	2.사용자 요구사항 관리 및 비즈니스 프로세스와의 일치	총 6문항 (2-1 ~ 2-6)
	3.프로젝트 일정 및 계획	총 9문항 (3-1 ~ 3-9)
	4.프로젝트 인력구성	총 5문항 (4-1 ~ 4-5)
	5.사용자 관리 및 참여의식	총 6문항 (5-1 ~ 5-6)
	6.프로젝트 관련조직 관리	총 6문항 (6-1 ~ 6-6)
	7.프로젝트의 공식적 Sponsorship	총 4문항 (7-1 ~ 7-4)
	8.프로젝트팀 내/외의 원활한 의사소통	총 5문항 (8-1 ~ 8-5)
	9.기술적인 이슈	총 4문항 (9-1 ~ 9-4)
	10.프로젝트 외부의 환경적인 요인	총 4문항 (10-1 ~ 10-4)
	11.비용	총 2문항 (11-1 ~ 11-2)
소프트웨어 패키지로 프로젝트 수행시	1.프로젝트 관리	총 8문항 (1-1 ~ 1-8)
	2.사용자 요구사항 관리 및 비즈니스 프로세스와의 일치	총 6문항 (2-1 ~ 2-6)
	3.프로젝트 일정 및 계획	총 9문항 (3-1 ~ 3-9)
	4.프로젝트 인력구성	총 5문항 (4-1 ~ 4-5)
	5.사용자 관리 및 참여의식	총 6문항 (5-1 ~ 5-6)
	6.프로젝트 관련조직 관리	총 6문항 (6-1 ~ 6-6)
	7.프로젝트의 공식적 Sponsorship	총 4문항 (7-1 ~ 7-4)
	8.프로젝트팀 내/외의 원활한 의사소통	총 5문항 (8-1 ~ 8-5)
	9.기술적인 이슈	총 4문항 (9-1 ~ 9-4)
	10.프로젝트 외부의 환경적인 요인	총 4문항 (10-1 ~ 10-4)
	11.비용	총 2문항 (11-1 ~ 11-2)

3.3 자료처리 및 분석 방법

최종 회수된 설문지의 유효 자료에 대하여 통계 프로그램인 SPSS(Ver 12.0)를 사용하여, 크론바 알파와 요인 분석을 통하여 측정도구의 신뢰성과 타당성을 분석하였다. 가설 1에 대해서는 두 가지 방안에 대한 위험 요인별 평균 비교를 통해 중요 순서대로 리스트를 만들어 두 가지 경우를 비교하였다. 두 번째 가설 검증을 위하여 Paired-T test를 실시하여 각 위험 요인별 두 그룹간 인식의 차이를 분석하였다.

Ⅳ. 분석 결과

4.1 표본의 특성

설문에 응한 응답자의 프로젝트 수행경험은 <표  3>과 같다. 즉, 응답자들 중 87명이 4번 이상의 프로젝트 경험이 있었다. 경험한 프로젝트 수행기간에 대한 응답 결과는 <표  4>와 같다. 그리고 응답자들 중  59명이 프로젝트를 수행하기 전과 수행한 후 경험한 위험요인을 다르게 생각한다고  답변하였다.

<표 4> 경험한 프로젝트의 수행기간별 횟수별 통계

	0 ～ 5회	6 ～ 10회	11 ～ 15회	16 ～ 20회	21회 이상
개발 언어 사용	59 명	29 명	7 명	3 명	2 명
패키지 적용	77 명	18 명	2 명	1 명	1 명

4.2 측정도구의 신뢰성과 타당성 검증

<표 3> 프로젝트 수행 경험

	0 ～ 5회	6 ～ 10회	11 ～ 15회	16 ～ 20회
신규 시스템 구축	53 명	39 명	4 명	4 명
기존 시스템 증설	89 명	11 명	0 명	0 명
컨설팅	91 명	8 명	0 명	0 명

신뢰성 분석이란 측정도구의 일관성, 안정성, 정확성, 예측 가능성을 의미하는 것으로 타당성과 함께 측정 도구가 갖추어야 할 구비요건으로 간주된다. 일반적으로 동일한 개념에 대하여 비교 가능한 독립된 측정도구를 사용하여 측정을 반복하였을 때 시간이나 상황에 따라 영향을 받지 않고 동일하거나 또는 유사한 측정값을 얻을 가능성을 의미한다. 본 연구에서는 수집된 자료의 신뢰성을 분석하는 방법으로 내적 일관성 측정방식을 채택하였다. 측정 항목간의 내적 일관성을 측정하기 위해서는 Cronbach’s 알파계수를 이용하였다, 일반적으로 알파값이 0.7을 넘으면 신뢰성이 상당히 양호한 것으로 평가된다. 본 연구의 측정도구의 신뢰성 검증 결과는 아래 <표 7>에서 보듯이 최하 0.724에서 0.912까지의 값을 나타내므로 전반적으로 신뢰할 만 하다고 판단된다.

타당성은 측정도구가 구성개념이 측정하고자 하는 개념이나 속성을 정확히 잘 반영하였는가를 알아보기 위해 검증하는 것으로 본 연구에서는 탐색적 요인 분석을 실시하였다. 요인 분석을 실시하기 전에 수집된 자료가 이에 적합한지를 검증하기 위해 상관 행렬과 Bartlett검정 및 KMO(Kaiser Meyer Olkin) 표본 적합도 검증을 실시하였고, 그 결과는 <표 5> 및 <표 6>과 같다. <표 5>에 나타난 검증 결과에서 보듯이 KMO값이 .757로 나타남으로써 KMO값이 1에 가까워 본 측정도구의 적합도가 인정되었다. 또한, Bartlett의 검정에서 유의확률이 0.000으로 "상관관계 행렬이 단위행렬이다"라는 영가설을 기각함으로써 요인 분석의 사용이 적합하며, 공통요인이 존재한다는 결론을 내릴 수 있다.

<표 5 > KMO and Bartlett's Test

Kaiser-Meyer-Olkin 표본 적합도		.757
Bartlett의 검정	근사 Chi-Square	2736.624
	자유도	903
	유의확률	.000

한편 변수들 간의 상관관계 분석을 하여 상관 계수가 0.2~0.4사이에 있으면 낮은 상관관계, 0.4이상이면 높은 상관관계, 0.8 이상이면 다중 공선성의 가능성이 있다. <표 6>에서 본 연구의 측정 결과를 보면 상관관계가 다소 높긴 하지만 모두 0.8 이하이기 때문에 큰 문제가 되지 않는다. 이 결과로 요인 분석을 실시하는데 문제가 없음을 확인하고 요인 분석을 진행하였다.

<표 6> 위험요인 그룹별 상관관계

	방법론 및 일정 관리	사용자 태도	외부 요인	SI/ 경영진 지원	프로젝 트 조직 관리	프로젝 트 인력	기술적 이슈	요구사항 관리	팀 내외 의사 소통
방법론 및 일정관리	1
사용자 태도	.578***	1
외부 요인	.545***	.529***	1
SI 및 경영진 지원	.612***	.576***	.498***	1
프로젝트 조직관리	.485***	.626***	.527***	.509***	1
프로젝트 인력	.624***	.467***	.516***	.444***	.481***	1
기술적인 이슈	.629***	.346***	.427***	.461***	.338***	.620***	1
요구사항 관리	.506***	.237**	.324***	.282**	.314***	.548***	.393***	1
팀 내외 의사소통	.701***	.606***	.483***	.626***	.596***	.566***	.570***	.350***	1
* p<0.1, **p<0.05, ***p<0.001

본 연구에서의 요인 회전은 Kaiser정규화가 있는 Varimax를 이용하였다. 요인분석 결과는 <표 7>과 같으며, 이 과정에서 18개 위험요인이 제거되고, 9개의 그룹으로 다시 재구성되었는데, 요인분석 결과 제거된 위험요인은 <표 8>과 같다.

4.3 가설 검정

가설을 검증하기 위하여 <표10>,<표11>과

<표 7> 신뢰성 및 타당성 검증 결과

성분										클론 바 알파
위험요인	1	2	3	4	5	6	7	8	9
효과적인 프로젝트 관리 방법론 부재	.523	.240	.024	.409	.102	-.100	.338	.261	.010	0.898 (개발) 0.799 (패키 지)
부적합한 계획 수립 혹은 미수립	.636	.329	.188	.080	.028	-.033	.027	.214	.360
프로젝트 일정	.703	.336	.197	.126	.057	.076	.143	.095	.259
인위적으로 조정된 일정	.644	.343	.185	.023	.099	.232	.278	.229	.007
프로젝트에 대한 공수 부족	.721	-.004	.089	-.004	.013	.297	.253	.023	.022
프로젝트 단계들의 불명확한 순차 관계	.695	.126	.289	.213	.019	.002	.108	.017	.027
프로젝트 각각의 활동결과에 대한 예측의 어려움	.626	.044	.200	.259	.219	.177	.051	.194	.157
프로젝트 발주 담당자의 책임감, 주인의식 부족	.219	.691	.047	.277	.359	.164	.097	.139	.089	0.908 (개발) 0.875 (패키지)
사용자의 능동적인 참여 부족	.169	.834	.106	.118	.175	.106	.141	.033	.135
시스템도입으로 발생하는 변화를 거부하는 태도	.156	.813	.203	.001	.049	.070	-.067	.035	.212
구축되는 시스템 목적에 대한 사용자 이해 부족	.182	.697	.237	.265	.136	.089	.090	-.086	.232
도입되는 시스템의 활용성에 대한 부정적태도	.105	.652	.270	.083	.123	.110	.133	-.107	.247
프로젝트를 불안정하게 만드는 기업환경의 변화	.108	.335	.778	-.047	-.103	.066	.169	.161	.066	0.876 (개발) 0.864 (패키지)
비즈니스 환경 변화에 의한 범위, 목적의 변화	.275	.141	.773	.015	.197	.029	.055	.202	-.031
다른 우선적인 프로젝트의 선점으로 일정충돌	.131	-.019	.769	.136	.355	.060	-.113	.075	.329
정치적인 이유등으로 실패하도록 의도된 프로젝트	.260	.330	.634	.135	.212	.063	.096	.089	.270
프로젝트에 대한 잘못된 예산 책정	.277	.180	.695	.265	.125	.102	.154	-.174	-.104
유지보수 및 교육을 고려하지 않은 비용 산정	.057	.097	.777	.179	.038	.286	.045	-.024	-.001
복수의벤더로 인한 통합의 복잡화	.095	-.058	.195	.720	-.136	-.201	.087	.211	.132	0.831 (개발) 0.783 (패키지)
외부 컨설턴트와 벤더들의 불충분한 역할 수행	.323	.151	.054	.614	.151	.184	.224	.332	.042
최고 경영진의 프로젝트에 대한 지원 부족	.239	.319	-.028	.633	.188	.226	.280	-.239	-.016
최고 경영진과의 관계 관리의 부족	.153	.459	.184	.650	.060	.087	.106	-.230	.180
경영진,프로젝트 Owner의 변화	.102	.289	.408	.621	.205	.202	.053	-.173	.186
사용자부서간의 마찰	.265	.276	.156	-.064	.717	.232	.036	.025	.250	0.847 (개발) 0.862 (패키지)
프로젝트 관련 이해 관계자들을 규명 실패	.023	.388	.344	.022	.661	-.034	.068	.086	.057
프로젝트 팀과 이해관계자들 과의 복합적인 관계	-.039	.328	.259	.114	.786	.058	.139	.114	.154
프로젝트 진행에 대한 기업의 지원 부족	.314	-.003	-.068	.213	.520	.349	.119	-.225	.379
부족하거나 과도한 수의 프로젝트 인원	.341	-.004	.164	.182	.218	.682	-.018	.286	.066	0.838 (개발) 0.745 (패키지)
적합한기술,지식,경험을 갖추지 못한 고객측 임원	.057	.128	.073	.042	.070	.877	.161	.080	.033
사용자측 대표자들의 경험 부족	.112	.198	.210	-.035	.040	.831	.047	-.022	.130
잘못된개발 전략	.482	.031	.195	.204	.136	.093	.551	.183	-.086	0.810 (개발) 0.757 (패키지)
검증되지 않은 새로운 기술의 사용	.103	.107	.160	.009	-.090	.006	.804	.107	.291
기술적으로 복잡한 프로젝트	.224	.034	-.075	.180	.091	.111	.819	.060	.087
기존 시스템 인프라와 자원의 부족	.273	.192	.239	.180	.284	.172	.605	.008	.138
변화 관리	.122	-.072	.127	.295	.446	.323	.106	.558	.070	0.796 (개발) 0.718 (패키지)
잘못된 요구사항 정의	.226	.030	.125	-.051	.074	.211	.097	.824	.042
고객 요구사항의 변화	.099	-.007	.027	-.006	-.038	-.070	.088	.885	-.086
고객과 중간 역할 부재	.546	.364	.154	.321	.120	-.025	.107	-.056	.503	0.857 (개발) 0.797 (패키지)
프로젝트 팀원간의 정보 공유 부족	.262	.271	.101	.183	.257	-.022	.132	.004	.747
개발팀의 요구에 대한 응답의 지연	.080	.251	-.039	.329	.189	.270	.271	.279	.593
프로젝트 팀원간의 의견 충돌	.059	.226	.123	-.036	.089	.166	.181	-.121	.727

<표 8> 요인분석 결과 제거된 위험요인

문항번호	위험요인
1-1	위험관리 활동의 부족
1-2	프로젝트 관리자의 효과적인 프로젝트 관리기술 부족
1-8	계약사항에 대한 관리
2-3	산출물에 대한 고객의 과도한 기대
2-4	외부 사용자에 대한 고려 미비
2-5	업무보다는 기술을 우선적으로 고려
2-6	기업 문화와 새로운 시스템에 필요한 비즈니스 프로세스 변화간의 불일치
3-1	과도한 프로젝트 범위
3-2	잘못 정의된 범위/목적
3-9	시스템 관리직원을 위한 기술 전수 및 교육
4-1	프로젝트 인력의 기술,업무지식,경험의 부족
4-2	프로젝트 진행중의 주요한 인력 손실
5-5	외부 컨설턴트에 대한 과도한 의존으로 인한 내부 인력의 불충분한 참여
6-1	프로젝트 팀과의 고객 각각의 역할과 책임에 대한 잘못된 정의
6-2	고객의 컨설턴트, 벤더, 하위계약자 전체에 대한 통제 부족
7-4	프로젝트의 대한 공식적인 승인 획득 실패
8-4	프로젝트 팀원과 사용자간의 의견 충돌
9-1	시스템의 유연성(기존 시스템과의 연계 및 확장성) 부족

같이 각 요인별 평균과 분산 그리고 그룹간의 차이를 검증하기 위해 paired-t 분석을 실시하였다.

4.3.1 개발 방식에 따라 위험요인 중요도에 대한 인식의 차이

가설 1을 검증하기 위해 각 위험 요인들의 평균이 높은 순서대로 나열한 결과는 <표 10>과 같다. 소프트웨어 개발 프로젝트의 경우 잘못된 개발 전략이 프로젝트 리스크에 가장 큰 영향을 미친다고 인지하는 반면, 패키지를 이용하는 경우에는 잘못된 요구사항 정의가 가장 큰 영향을 미친다고 분석되었다. 이는 소프트웨어 개발의 경우 개발 전략이 체계적으로 수립되느냐 아니냐에 따라 프로젝트의 산출물에 많은 영향을 미치게 되며, 그 결과가 프로젝트의 리스크에 많은 영향을 준다고 인식하는 것으로 이해할 수 있다. 그 외에 소프트웨어 개발 프로젝트의 경우 부족하거나 과도한 수의 프로젝트 인원 등이 중요한 요인으로 인식되었다. 이는 프로그램 개발 시 개발자들 간의 적절한 작업량 분산과 유기적인 협력관계 및 정보의 공유가 중요하므로, 이를 실행하기 위해 전체 구현시스템 개발에 필요한 적절한 인원의 투입이 중요하다는 것을 알 수 있다, 투입 인원이 너무 부족한 경우뿐 아니라 너무 과도한 경우에도 개발자간의 협력관계 및 책임의식의 형성에 영향을 주므로 이것이 전체 프로젝트의 성공적인 수행에 영향을 미치는 것으로 분석된다. 반면에 패키지 개발의 경우는 프로젝트 진행을 위한 기존 시스템 인프라와 자원의 부족, 외부 컨설턴트와 벤더들의 불충분한 역할과 책임 수행이 프로젝트 리스크에 큰 영향을 미치는 것으로 분석되었다. 이는 특정 패키지 적용을 위해서 일반적으로 그 패키지가 요구하는 시스템 환경과 자원이 충족되어야 하며, 이와 같은 패키지의 시스템 선수 조건들이 기존 시스템 환경에서 충족되지 않는 경우 프로젝트의 성과에 영향을 줄 수 있다고 인지하는 것으로 해석된다. 또한 프로그램 언어로 시스템을 개발하는 경우와 달리 패키지 구축의 경우 해당 패키지에 대한 기술과 경험, 그리고 비즈니스 요건과의 접목 등에 대하여 시스템을 구축하는 SI사 및 솔루션 패키지 벤더들에 대한 의존도가 높다. 따라서 이들의 역할과 책임 수행이 상대적으로 중요하게 인식됨을 알 수 있다. 이는 패키지 공급자의 기술 능력 및 각종 서비스에 대해 신중히 고려한 경우 도입한 패키지의 기본적 질이 좋아지고, 패키지 설치 과정에서 공급자로부터 많은 지원을 받을수록 패키지 도입 및 운영으로 인하여 얻게 되는 효과를 극대화할 수 있다는 신현식(1990)의 연구결과를 통해서도 패키지 도입의 경우 제공 벤더나 외부 업체의 서비스 또는 기술지원 등의 역할과 책임수행이 중요하다는 것을 알 수 있다.

<표 9> 두 개발방법론에서 위험요인의 중요도 순위

4.3.2 자체 개발과 패키지 적용시 위험 요인 유형 및 각 요인 별 참여자들의 인식의 차이

자체 개발과 패키지 적용 시 위험요인에 대한 인식의 차이를 분석하기 위해 paired-t 분석을 실시하였으며, 그 중 위험요인 유형별로도 통계값과 T 분석을 진행하였고, 그 결과는 <표 10>과 같다. 결과적으로, 프로젝트 관리를 위한 방법론 및 일정 관리 유형(p<0.01)과 프로젝트 인력구성 유형(p<0.1)이 자체 개발하는 경우, 그리고 기술적인 이슈 유형(p<0.1)이 패키지 적용의 경우 프로젝트 리스크에 보다 큰 영향을 미치는 것으로 나타나, 위험요인의 유형별로 두 그룹의 차이를 알 수 있었다.

이어서 구체적으로 각 위험 요인 별로 두 그룹 사이의 차이를 조사하였으며, 그 결과를 정리한 내용은 <표 11>과 같다.

우선 프로젝트 관리를 위한 방법론 및 일정관리 유형에서는 효과적인 프로젝트 관리 방법론 부재(p<0.01), 인위적으로 조정된 일정(p<0.1), 프로젝트 단계들의 불명확한 순차관계(p<0.5), 프로젝트 각각의 활동결과에 대한 예측의 어려움(p<0.01)들이 자체 개발의 경우 프로젝트 리스크에 보다 큰 영향을 미치는 것으로 나타났다. 이는 프로그램 언어로 개발하는 경우 프로젝트 관리 방법론에 따라 효과적으로 프로젝트를 관리하고, 계획된 일정과 순차관계에 따라 프로젝트를 진행하는 것이 패키지를 적용하는 경우에 비해 개발자들의 생산성과 개발 산출물의 품질에 많은 영향을 준다고 인식하는 것으로 해석할 수 있다.

또한 사용자의 참여의식 및 태도 위험요인 유형에서는 프로젝트에 대한 발주 담당자의 책임감, 주인의식 부족(p<0.1), 정보시스템 도입으로 발생하는 변화를 거부하는 태도(p<0.1), 도입되는 정보시스템의 활용성에 대한 부정적 태도(p<0.5)들이 소프트웨어 패키지를 적용하는 경우 프로젝트의 리스크에 많은 영향을 미치는 것으로 분석되었다. 이는 솔루션 패키지 도입의 경우 자신의 업무 프로세스 요건에 따라 시스템을 새로이 개발하는 것이 아니라, 기존에 이미 개발된 패키지를 도입하여 자신의 업무 프로세스에 접목하여 수용하는 것이므로, 이 작업을 위한 프로젝트 기간 동안의 책임감 및 주인의식, 그리고 새로운 시스템 환경 및 프로세스로 변화하는 것에 대한 거부감을 축소시키는 것이 중요한 요소임을 나타내고 있다. 도입된 소프트웨어 패키지가 그 기업의 상황에 적합하여 그 조직이 가지고 있는 경영관리상의 문제를 해결하고, 도입의 변화에 대한 현업 부서의 저항을 최소화하면서, 비즈니스 목적을 달성하게 하는 작업이 매우 복잡하고 신중하게 고려되어야 할 작업(Blaustein, 1988)임을 알 수 있다. 따라서 어떤 패키지를 도입하더라도 그것에는 기업의 요구에 일치하지 않는 부분이 있을  수  밖에 없으므로, 가급적이면 패키지와 기업의 요구가 일치하지 않는 부분을 최소화할 수 있도록 패키지를 선택하는 것이 매우 중요하고. 사용자 부서의 요구와 패키지의 기능이 일치하는 정도가 시스템의 성공과 실패에 있어서 매우 중요한 영향을 미친다고 할 수 있다(신현식, 1990). 이는 해당 패키지가 그 기업의 업무 프로세스와 유연하게 접목될 수 있느냐 하는 측면이 이슈가 될 수 있다. 이는 곧 정보시스템 사용자들이 개발된 시스템을 잘 활용할 수 있느냐 하는 활용성과도 관련이 될 것이다.

한편, 프로젝트 수행 SI 역할 및 경영진의 지원 위험요인 유형에서는 경영진, 프로젝트 Owner의 변화(p<0.01)가 소프트웨어 패키지를 적용하는 경우 프로젝트 리스크에 더 영향을 미치는 것으로 분석되었다. 이는 경영진 또는 프로젝트 Owner의 변화가 프로젝트의 사용자들과 관계된 변화이며, 사용자 요건이나 프로젝트 범위의 변화와 관련이 될 수 있다. 따라서 사용자 요건 또는 프로젝트의 변경을 잘 수용하느냐 하는 측면을 살펴보면 프로그램

<표 10> 위험요인 유형별 통계값 및 T 분석 결과

위험요인 유형	평균 개발 패키지		분산 개발 패키지		T값	자유도	유의 확률
1. 프로젝트관리를 위한 방법론 및 일정 관리	5.3339	5.2610	.964	.634	3.402	64	.001***
2. 사용자의 참여의식및 태도	4.8899	4.9680	1.156	1.146	.294	64	.770
3. 프로젝트 외부의 환경적인 요인 및 비용	4.9754	5.0644	1.283	1.202	-.225	64	.823
4. 프로젝트의수행 SI 역할 및 경영진의 지원	4.7978	4.9813	1.233	1.213	.000	64	1.000
5. 사용자측 프로젝트 관련 조직 관리	4.6910	4.8533	1.391	1.419	-.410	64	.683
6. 프로젝트 인력구성	5.1843	5.1387	.890	.691	1.702	64	.094*
7. 기술적인 이슈	5.3567	5.4233	1.112	.997	1.857	64	.068*
8. 사용자요구사항 관리	5.4569	5.5135	1.289	1.264	.588	63	.559
9. 프로젝트팀내/외의 원활한 의사소통	5.0590	5.1333	1.148	.892	1.591	64	.117
* p<0.1, **p<0.05, ***p<0.001

언어로 개발하는 경우에 비해 패키지를 적용하는 경우 그 변화에 대한 수용성이 상대적으로 낮다고 인식하는 것으로 해석할 수 있다.

그리고 프로젝트 인력구성 위험요인 유형에서는 부족하거나 과도한 수의 프로젝트 인원(p<0.1)이 개발하는 경우에, 그리고 프로젝트에 적합한 기술, 지식, 경험을 갖추지 못한 고객측 인원(p<0.1)이 패키지를 사용하는 경우에 더 큰 영향을 미치는 것으로 나타났다. 이는 개발에 참여하는 인원의 수가 소프트웨어 개발 프로젝트의 중요한 고려 요소임을 알 수 있다. 반면에 패키지 적용의 경우는 개발하는 경우와 비교하여 패키지를 적용하는 기업의 인원들이 패키지 자체에 대한 기술과 지식을 가지고 경험을 활용하여 프로젝트에 적용하는 것이 상대적으로 중요한 것으로 인식하고 있다는 결과로 해석할 수 있다.

또한 기술적인 이슈 위험요인 유형에서는 자체 개발의 경우 잘못된 개발 전략(p<0.01)이 리스크에 많은 영향을 미친다고 인식되었다. 이는 패키지를 적용하는 경우에는 패키지에서 제공하는 개발 전략과 과거에 적용했던 경험을 활용할 수 있는 반면, 자체 개발의 경우에는 프로젝트 내에서 개발 전략이 체계적으로 관리되었는지 아닌지에 따라 개발 결과에 많은 영향을 받을 수 있다는 것이 그 요인으로 작용한 한 것으로 볼 수 있다.

마지막으로 프로젝트 팀내/외의 원활한 의사소통 위험요인 유형에서는 프로젝트 팀원 간의 정보 공유 부족(p<0.01)'이 자체 개발의 경우 프로젝트 리스크에 심각한 영향을 주는 것으로 분석되었다. 이는 프로젝트 팀원 간의 정보공유가 패키지를 적용하는 경우는 패키지에서 제공되는 정보를 공유하여 이 정보를 적용하면서 프로젝트를 진행하게 되므로 프로젝트 기간 내 팀원 간의 정보 공유관리에 그리 의존하지 않게 되지만, 프로그램 개발의 경우에는 개발자들 간의 정보공유로 유기적인 개발 작업을 진행할 수 있다. 이로 인해 전체적으로 효과적이고 생산성 있는 개발 작업과 품질을 보장할 수 있으므로, 상대적으로 프로젝트 내에서 팀원 간의 정보공유 관리가 매우 중요하게 작용함을 알 수 있다.

<표 11> 위험 요인별 통계값 및 T 분석 결과

위험요인 유형	프로젝트 위험요인	평균 개발 패키지		분산 개발 패키지		T분석 T값 자유도 유의확률
1. 프로젝트 관리를 위한 방법론 및 일정 관리	효과적인 프로젝트 관리 방법론부재	5.12	4.78	2.269	1.809	3.780	61	0.000 ***
	부적합한 계획 수립 혹은 미수립	5.78	5.80	1.321	1.135	1.417	63	0.162
	프로젝트 일정	5.76	5.79	1.137	0.900	1.454	63	0.151
	인위적으로 조정된 일정	5.45	5.52	1.400	1.059	1.939	61	0.057*
	프로젝트에 대한 공수 부족	5.49	5.53	1.389	0.982	1.633	63	0.107
	프로젝트 단계들의 불명확한 순차관계	5.14	5.07	1.446	1.259	2.123	61	0.038**
	프로젝트 각각의 활동결과에 대한 예측의 어려움	4.88	4.81	1.559	1.262	2.676	63	0.009***
2. 사용자의 참여 의식 및 태도	프로젝트 발주 담당자의 책임감, 주인의식 부족	5.07	5.11	1.950	2.016	1.947	62	0.056*
	사용자의 능동적인 참여 부족	5.05	5.05	1.423	1.553	1.000	61	0.321
	시스템 도입으로 발생하는 변화를 거부하는 태도	4.98	5.19	1.409	1.443	-1.937	62	0.057*
	구축되는 시스템 목적에 대한 사용자 이해 부족	4.78	4.93	1.515	1.558	-0.466	60	0.643
	도입되는 시스템의 활용성에 대한 부정적 태도	4.80	5.09	1.572	1.648	-2.451	62	0.017**
3. 프로젝트 외부의 환경적인 요인 및 비용	프로젝트를 불안정하게 만드는 기업환경의 변화	4.88	4.97	1.628	1.643	-0.753	63	0.454
	비즈니스 환경 변화에 의한 범위/목적의 변화	4.91	5.00	1.991	1.889	0.148	62	0.883
	다른 우선적인 프로젝트의 선점으로 일정충돌	4.87	5.03	2.088	1.749	-0.155	63	0.877
	정치적인 이유 등으로 실패하도록 의도된 프로젝트	5.05	5.25	3.676	3.030	-0.961	64	0.340
	프로젝트에 대한 잘못된 예산 책정	5.19	5.36	1.859	1.909	-0.630	64	0.531
	유지보수 및 교육을 고려하지 않은 비용 산정	5.07	5.11	1.444	1.907	-0.139	64	0.890
4.프로젝트의 수행 SI역할 및경영진의 지원	복수의 벤더로 인한 통합의 복잡화	4.96	5.01	2.021	2.616	0.64	63	0.949
	외부 컨설턴트와 벤더들의 불충분한 역할 수행	5.33	5.49	1.488	1.948	0.244	62	0.808
	최고 경영진의 프로젝트에 대한 지원 부족	4.82	5.07	2.399	2.252	0.504	63	0.616
	최고 경영진과의 관계관리의 부족	4.61	4.84	2.171	2.165	0.191	62	0.849
	경영진,프로젝트 Owner의 변화	4.53	4.90	1.969	2.005	-2.965	61	0.004***
5. 사용자측 프로젝트 관련 조직 관리	사용자 부서간의 마찰	4.75	4.92	1.984	1.856	-1.263	62	0.211
	프로젝트 관련 이해 관계자들을 규명 실패	4.76	4.92	2.114	1.911	-1.044	62	0.300
	프로젝트 팀과 이해관계자들과의 복합적인 관계	4.82	4.84	1.829	1.727	0.000	62	1.000
	프로젝트 진행에 대한 팀 외부(조직)의 지원 부족	4.59	5.00	1.920	1.699	-0.747	61	0.458
6. 프로젝트 인력구성	부족하거나 과도한 수의 프로젝트 인원	5.25	5.17	1.370	0.956	1.987	63	0.051*
	적합한 기술, 지식, 경험을 갖추지 못한 고객측 인원	5.11	5.12	1.442	1.341	1.841	62	0.070*
	사용자측 대표자들의 경험 부족	4.82	4.95	1.185	1.375	0.131	63	0.896
7. 기술적인 이슈	잘못된 개발 전략	5.84	5.27	1.361	2.282	4.209	63	0.000***
	검증되지 않은 새로운 기술의 사용	5.41	5.55	1.095	1.792	0.264	64	0.792
	기술적으로 복잡한 프로젝트	5.25	5.45	1.477	1.521	0.459	64	0.647
	기존 시스템 인프라와 자원의 부족	5.10	5.57	1.656	1.235	-1.595	63	0.116
8. 사용자 요구사항 관리	변화 관리	5.09	5.10	1.900	2.089	1.033	62	0.306
	잘못된 요구사항 정의	5.84	5.89	1.768	1.682	0.782	61	0.437
	고객 요구사항의 변화	5.62	5.77	1.409	1.768	-0.096	62	0.924
9. 프로젝트 팀내/외의 원활한 의사소통	고객과 중간 역할 부재	5.19	5.37	1.588	1.210	-0.198	63	0.843
	프로젝트 팀원간의 정보 공유 부족	5.24	5.19	1.488	1.306	2,961	62	0.004***
	개발팀의 요구에 대한 응답의 지연	5.04	5.19	1.339	1.316	1.345	63	0.184
	프로젝트 팀원간의 의견 충돌	4.88	4.92	1.655	1.829	1.498	62	0.139
* p<0.1, **p<0.05, ***p<0.001

<표 12> 가설2 검증 결과 요약

위험요인 유형	채택된 위험요인		기각된 위험요인
	자체 개발	패키지
1.프로젝트 관리를 위한 방법론 및 일정 관리	-효과적인 프로젝트 관리 방법론 부재(***) -인위적으로 조정된 일정(*) -프로젝트 단계들의 불명확한 순차관계(**) -프로젝트 각각의 활동결과에 대한 예측의 어려움(***)		-부적합한 계획 수립 혹은 미수립 -초기에 신중히 고려하지 않은 일정 -프로젝트에 대한 공수 부족
2. 사용자의 참여의식및 태도		- 프로젝트에 대한 발주 담당자의 책임감, 주인의식 부족(*) - 정보시스템 도입으로 발생하는 변화를 거부하는 태도(*) - 도입되는 정보시스템의 활용성에 대한 부정적 태도(**)	-사용자의 능동적인 참여 부족 -구축되는 정보시스템 목적에 대한 사용자 이해 부족
3. 프로젝트 외부의 환경적인 요인 및 비용			-프로젝트를 불안정하게 만드는 기업환경의 변화 -환경 변화에 의한 범위/목적의 변화 -더 높은 우선권을 가진 프로젝트의 선점으로 인한 일정 충돌 -정치적인 이유 등으로 실패하도록 의도된 프로젝트 -프로젝트에 대한 잘못된 예산 책정 -유지보수 및 교육을 무시한 비용 산정
4. 프로젝트 수행 SI 역할 및 경영진의 지원		- 경영진,프로젝트 Owner의 변화(***)	-복수의 벤더로 인한 통합의 복잡화 -외부 컨설턴트와 벤더들의 불충분한 역할과 책임 수행 -최고 경영진의 지원 부족 -최고 경영진과의 관계 관리의 부족
5. 사용자측 프로젝트 관련 조직 관리			-사용자 부서간의 마찰 -프로젝트와 관련된 모든 이해 관계자들을 규명하는데 실패 -프로젝트 팀과 이해관계자들과의 복합적인 관계(다수의 이해관계자) - 팀 외부(조직)의 지원 부족
6. 프로젝트 인력 구성	- 부족하거나 과도한 수의 프로젝트 인원(*)	- 프로젝트에 적합한 기술,지식, - 경험을 갖추지 못한 고객 측 인원(*)
7. 기술적인 이슈	- 잘못된 개발 전략(***)		-검증되지 않은 새로운 기술의 사용 -기술적으로 복잡한 프로젝트 -기존 시스템 인프라와 자원의 부족
8. 사용자 요구사항 관리			-변화 관리 (Change management) -잘못된 요구사항 정의 -고객 요구사항의 변화
9. 프로젝트 팀내/외의 원활한 의사소통	- 프로젝트 팀원 간의 정보 공유 부족(***)		-고객과 프로젝트 팀과의 중간 역할 부재 -개발팀의 요구에 대한 응답의 지연 -프로젝트 팀원간의 의견 충돌
* p<0.1, **p<0.05, ***p<0.001

4.4 검증 결과 논의

위의 검증결과를 볼 때 소프트웨어 개발 방법의 경우 잘못된 개발 전략이 가장 큰 위험요인으로 인식되었으며, 그 외에도 프로젝트 진행중의 주요한 인력 손실, 프로젝트 인력의 기술, 업무지식, 경험의 부족 등이 중요한 위험요인으로 인식되었다. 반면, 패키지 사용 시에는 프로젝트 진행을 위한 기존 시스템 인프라와 자원의 부족, 외부 컨설턴트와 벤더들의 불충분한 역할과 책임 수행 등이 중요한 위험요인으로 인식되었다. 즉, 자체 개발의 경우는 프로젝트 내 시스템 개발과정에 관련된 요인들이 중요하다고 인식되는 반면, 패키지의 경우 패키지 도입을 위해 외부 인력들의 지원과 기업의 업무 프로세스 및 기존 시스템과의 연계 등 패키지를 기업에 적용하는 데 관련된 요인들이 중요하게 인식된다는 결론을 얻을 수 있다. 또한 두 가지 경우의 프로젝트 위험요인에 대한 인식의 차이가 있는 분야를 비교해보면, 자체 개발의 경우는 방법론, 일정관리, 인력에 대한 관리, 정보공유 등 주로 프로젝트의 관리와 관련이 있는 위험요인들이 많이 있어 개발 과정에 대한 관리가 중요하다는 것을 알 수 있다. 반면, 패키지 적용의 경우는 사용자들이 이를 수용하는 참여의식과 태도 및 기술에 관련되는 요인들이 많이 있으며, 이는 패키지 적용시 도입 패키지가 해당 기업의 업무 프로세스 및 사용자의 요건에 유연하게 적용될 수 있게 하는 것이 중요하다고 인식하는 것을 알 수 있다.

Ⅴ. 결  론

5.1 연구의 요약 및 의의

본 연구는 국내에서 IT 프로젝트를 수행하는 SI와 프로젝트를 발주하는 기업체의 인력들을 대상으로 프로젝트 위험요인들에 대한 인식을 재점검하여 프로젝트 수행 전 또는 수행 중에 점검해야 하는 위험요인들에 대해 연구하였다. 특히 프로젝트의 진행방법이 프로그램 개발언어를 가지고 개발하는 경우와 해당 솔루션 영역의 전문 벤더사가 제공하는 소프트웨어 패키지를 가지고 진행하는 경우를 비교 연구함으로써 각각의 경우에 적합한 프로젝트 위험요인 관리에 활용할 수 있도록 구분하여 실증분석을 수행하였다. 본 연구를 위해 국내 다수의 프로젝트 경험이 있는 기업체 및 SI사 직원들을 대상으로 59개의 위험요인들에 대해 자체 개발과 패키지 적용 두 가지 방법론의 위험요인 인식에 대한 118개의 설문을 진행하였다. 설문 응답 데이터로 paired-t 분석을 실시한 결과 자체 개발과 패키지 적용의 개발 방법론에 따라 프로젝트 리스크에 영향을 미치는 위험요인 우선순위에 차이가 있으며, 각 위험요인의 유형별 그리고 세부 위험요인 항목 별로 인식의 차이가 있음을 알 수 있었다. 결론적으로 자체 개발의 경우 개발을 위한 방법론 및 전략, 그리고 인력관리 등 개발 과정에서의 프로젝트 관리가 중요한 영향을 미치는 반면, 패키지 적용의 경우 기존에 이미 개발되어 있는 패키지를 기업에 적용하기 위해 도입된 패키지를 필요한 업무 프로세스 및 시스템 환경에의 수용 및 패키지 벤더의 지원, 그리고 이를 수용하려는 기업체 인원들의 태도 등이 중요한 영향을 미치고 있음을 알 수 있었다.

그동안 프로젝트의 리스크 관리에 관한 많은 문헌들이 있었으나, 이것을 소프트웨어 패키지냐 순수 개발이냐의 프로젝트 개발 방법론 차이에 따른 리스크 요인의 인식과 관련된 연구는 드물었다. 또한 단순히 패키지 적용과 자체 개발 측면에서 개발과정을 비교한 연구는 있었으나, 기업의 정보시스템 프로젝트가 리스크 관리가 중요하다는 부분을 감안하여 이를 프로젝트 리스크 측면에서 비교 연구한 문헌 또한 드물었다. 본 연구는 이런 개발 방법론의 인식의 차이에 따른 프로젝트 리스크 요인들을 연구함으로써 기존 프로젝트 위험요인 관련 연구 또는 개발 방법론의 차이에 따른 연구들과 차별화된 연구 내용을 제시하였다.

이 연구 결과로 향후 기업들이 정보시스템 프로젝트를 진행할 때 프로젝트 리스크 관리를 프로젝트 개발 방법에 따라 적합하게 관리할 수 있게 됨으로써 프로젝트의 리스크를 줄여 성공적인 프로젝트 수행이 가능하도록 하였다. 또한 패키지 도입의 경험이 없거나 많지 않은 기업의 경우, 이를 미리 예측하여 관리함으로써 익숙하지 않은 프로젝트 진행을 위해 중요한 정보로 제공할 수 있게 되었다.

5.2 본 연구의 시사점  및 제한점

지금까지는 프로젝트를 수행하는 SI사의 프로젝트 관리자나 수행자들이 프로젝트의 종류나 개발 방법론에 관계없이 일관적인 프로젝트 리스크 관리 방법론에 의해 프로젝트 리스크 관리를 진행하였으나, 본 연구 및 몇몇 선행 연구의 결과를 보면 향후에는 이 프로젝트 리스크 관리 방법론을 좀 더 세분화하여 프로젝트의 솔루션 분야, 개발 방법론의 차이, 그리고 프로젝트 관리자와 수행자, 또는 사용자들의 성향이나 경험, 그리고 영향력에 따라 다르게 접근할 필요가 있다. 특히 기업에서 정보시스템 구축 시 이미 개발되어 있는 소프트웨어 패키지를 도입하는 경우에는, 그 기업의 현재 업무 프로세스 및 유관 시스템과 가장 잘 융합될 수 있는 패키지의 선택이 중요하다. 또한 이를 최대한 사용자의 요건을 반영하여 구축함으로써 사용자들이 변화에 거부감을 가지지 않고 잘 활용할 수 있도록 하는 것이 중요하다. 또한 최근 기업들이 정보시스템 구축에 있어서 소프트웨어 패키지를 점점 많이 활용해 나가는 추세에 있는데 비해, 이에 대한 학문적인 연구는 그리 활발하지 않으므로, 일반 자체 개발 프로젝트와 패키지를 이용한 프로젝트의 특성을 비교한 본 연구가 향후 관련 연구의 참고 자료로 활용될 수 있을 것으로 기대된다.

하지만 본 연구는 다음과 같은 제한점을 지니고 있다. 첫째, 100개가 넘는 많은 수의 설문 문항을 통해 위험요인 인식에 대한 비교 연구를 진행하였으며, 이렇게 많은 설문 항목에 응답해야 하는 상황에서 자신의 생각을 정확히 표현하거나 판단하는데 어려움이 있을 수 있었던 것으로 추측된다. 향후에는 설문의 항목을 최대한 간소화하고 직관적으로 작성하여 응답자들이 좀 더 정확하고 성의 있는 응답을 할 수 있도록 하는 설문 방식에 대한 지속적인 고민이 필요할 것이다. 둘째, 기업들이 적용하고 있는 소프트웨어 패키지의 종류가 다양하여 이들 간의 특성에 차이가 있으므로 해당 정보시스템 분야를 기간계, 정보계 등 업무 성격에 따라 나누어서, 프로젝트의 유형에 따라 개발과 패키지의 위험요인 인식의 차이를 연구하는 것도 의미가 있을 것으로 판단된다. 셋째, 본 연구는 한 번의 설문을 통해 각 응답자의 전체적인 프로젝트 경험을 통해 인식되는 프로젝트 위험요인에 대해 조사하는 방법을 택했다. 이를 좀 더 정확하게 측정하기 위해서 해당 프로젝트를 수행하기 전과 직후, 두 번에 걸친 설문 결과를 비교함으로써 실제 프로젝트의 상황을 좀 더 정확하게 반영할 수 있을 것이다. 그러나 현실적으로 시간이나 조사방법의 한계에 의해 수행하지 못하였으므로 향후 이를 보완하여 프로젝트의 정확한 상황을 반영하여 연구를 진행할 수 있는 방법을 고려해보는 것도 연구의 정확성을 위해 많은 도움이 될 것으로 판단된다.  끝으로 T-test 방법만으로 두 가지 개발 방법론에 대해 비교 평가를 내리는 것이 다소 제한적이므로, 차후 연구 방법론을 좀 더 보강하여 여러 각도에서 신뢰성있는 비교 연구를 해보는 것도 향후 연구 과제로 진행할 수 있을 것이다.

참고문헌

김경내, “소프트웨어 개발 프로젝트의 위험관리,” 건국대학교정보통신대학원 석사학위 논문, 2000.

김용원, "데이터 웨어하우스 개발 프로젝트의 위험요인에 관한 탐색적 연구,” 한양대학교 경영정보대학원 석사학위 논문, 2005.

김태준, "국내 SI업체의 정보시스템 프로젝트 위험관리가 프로젝트 성과에 미치는 영향에 관한 연구,” 한국외대 경영정보대학원 석사학위 논문, 2004.

김혜정, “정보시스템 프로젝트 실패유형에 따른 위험요인에 관한 탐색적 연구,” 건국대학원 경영학과 석사학위 논문, 2002.

박정선, “정보시스템 프로젝트의 위험요인에 대한 현업과 전산인력의 인식도 차이,” 건국대학원 경영학과 석사학위 논문, 2004.

박진석, "SI환경에서 의사소통이 프로젝트 성공에 미치는 영향에 관한 연구,” 건국대학교 정보통신 대학원 석사학위 논문, 2004.

서창교, 정은희“프로젝트 위험과 위험관리가 소프트웨어 개발 프로젝트 성과에 미치는 영향,"  경영정보학연구, 13권, 2호, 2004, pp. 199-218.

신현식, "응용 소프트웨어 패키지 구입과정과 경영정보시스템 성과의 관계 분석," 한국과학기술원 경영과학과 석사학위 논문, 1990.

신현식, "정보시스템 외부조달 방법과 자체 개발 방법의 비교분석," 한국과학기술원 경영과학과 박사학위 논문, 1995.

오수진,  “SI프로젝트 범위증감(Escalation, De-escalation)에 영향을 미치는 위험요소 인지에 대한 연구," 한양대학교 경영대학원 석사학위 논문, 2002.

윤영준, "금융기관 IT프로젝트의 위험요인에 대한 실증연구,” 연세대학교 컴퓨터 공학 석사학위 논문, 2005.

이석준, 김혜정, 서현석 “정보시스템 프로젝트의 성과 영역별 위험요인에 관한 탐색적 연구," Journal of Information Technology Application& Management, 2004, pp. 103-120.

정경호, “요구사항 불확실성과 사용자 참여가 정보시스템 개발 프로젝트 성과에 미치는 영향에 관한 연구,” 한국외대 경영정보대학원 석사학위 논문, 2003.

조숙진, 이석준, 함유근 “정보시스템 프로젝트의 위험요인에 관한 실증연구,” 경영정보학 연구 제16권 제3호, 2006, pp. 143-158.

한경선, "CRM 프로젝트에 영향을 미치는 위험요인분석,” 한양대학교 경영학과 석사학위 논문, 2001.

현경일  "시스템 개발 방법이 정보의 질, 시스템 부서의 태도 및 지원에 미치는 영향: 상황적 연구," 연세대학교 경영대학원 석사학위 논문, 1991.

Barki, H., Rivard, S. & Talbot, J., "Toward an assessment of software development risk,” Journal of Management Information Systems, Vol. 10, No. 2, 1993, pp. 203-225.

Barki, H,, Rivard, S. & Talbot, J., "An integrative contingency model of software project risk management,” Journal of Management Information Systems, Vol. 17, No. 4, 2001, pp. 37-69.

Blaustein, E.B., "Planning for the Introduction of New Software," Journal of Systems Management, Vol. 39, No. 9, September 1988, pp. 6-9.

Boehm, B., "Software Risk Management Tutorial," Washington, DC:IEEE Computer Society Press. 1989.

Jiang, J,J., Klen, G. and Ellis, S.T., “A Measure of Software Development Risk,” Project Management Journal, Vol. 33, No. 3, 2002, pp. 30-41.

Johnson, J., "Turning Chaos into Success," Software Magazine, Vol. 19, 2000, pp. 30-39.

Kaiser, K,M., Bostrom, R.P., "Personality Characteristics of MIS Project Teams : An Empirical Study and Action-Research Design," MIS Quarterly, Vol. 6, No. 4, 1982, pp. 43-60.

Keil, M., Tiwana, A. & Bush, A., "Reconciling user and project manager perceptions of IT project risk:a Delphi study,” Info Systems J , 2002 Dec, pp. 103-119.

Love, P.E.D., Irani, Z., Standing, C., Lin, C., & Burn, J.M., "The enigma of evaluation: benefits, costs and risks of IT in Australian small-medium-sized enterprises,” Information & Management, Vol. 42, 2005, pp. 947-964.

Lynch, R.K., "Implementing Packaged Application Software: Hidden Costs and New Challenges," Systems, Objectives, Solutions, Vol. 4, 1984.

McKeen, J,D,, Guimaraes, T. & Wetherbe, J.C., “The Relationship between User Participation and User Satisfaction : An Investigation of Four Contingence Factors,” MIS Quarterly, Vol. 18, No. 4, December 1994, pp. 427-451.

Moynihan, T., "How experienced project managers assess risk,” IEEE Software, Vol. 14, 1997, pp. 35-42.

Peter E.D. Love, Zahir Irani, Craig Standing, Chad Lin, Janice M. Burn, "The egnima of evaluation: benefits, costs and risks of IT in Australian small-medium-sized enterprises," Information & Management, December 2004.

Schmidt, R., Lyytinen, K., Kail, M. & Cule, P., "Identifying software project risks: An international Delphi study," Journal of Management Information Systems, Vol. 17, No. 4, 2001, pp. 5-36.

Sitkin, S. B. & Pablo, A, L., "Reconceptualizing the Determinants of Risk Behavior," The Academy of Management Review, Vol. 17, No. 1. January 1992, pp. 9-38.

Tiwana, A., The knowledge Management Toolkit: Techniques for Building a Knowledge Management System, Prentice Hall, Upper Saddle River, NJ, 2000.

Watson, H. J. & Haley, B. J., "Data Warehousing: a framework and survey of practices," Journal of Data Warehousing, Vol. 2, 1997, pp. 10-17.

Willcocks, L. & Griffiths, C.,“Predicting Risk of Failure in Large-Scale Information Technology Projects,” Technological Forecasting and Social Change, Vol. 47, 1994, pp. 205-228.

박송미 (Song-Mee Park)

연세대학교 산업대학원 전산학과에서 석사학위를 취득하였으며, 현재 한국 IBM에 근무하면서 서울 벤처정보대학원대학교 박사학위 과정에 있다. 한국 IBM에서는 소프트웨어 사업부 정보관리팀에서 정보관리 솔루션 비즈니스를 진행하고 있으며, CRM, 데이터 웨어하우스, MDM(Master Data Management)등의 프로젝트를 지원하며, 이에 대한 솔루션 지식과 경험을 쌓았다. 주로 정보관리 솔루션 영역과 BPM, 프로젝트 관리 방법론, 그리고 프로젝트 리스크 관리에 대한 연구를 진행하였다.

채명신 (Myungshin Chae)

University of Illinois at Chicago에서 MIS 박사학위 취득하였으며 현재 서울벤처정보대학원의 정보경영학과 교수로 재직 중이다. e-Biz/모바일 비즈니스, IS의 전략적 도입 분야를 중심으로 연구를 진행하고 있다.

<Abstract>

A Study on Perception of Project Risk Factor

- Comparison between Software Package and Development with Program Language in Information System Project

Song-Mee Park․Myungsin Chae

It is critical to manage risks to complete IS(Information Systems) projects successfully. Identifying risk factors would be the first step for the project risk management. Previous research has discussed the issue with various points of view, such as different risk factors based on project types and roles involved in their projects. This paper empirically explored how people perceive different risk factors by project development methodology, between self-developing IS using programming language like C, Visual Basic and adapting software package already developed by software venders like ERP, CRM packages.

There are researches regarding project risk factors for project management in the several point of views. And there are also researches regarding comparison between self-developing and adapting software packages methodology in IS project. However, there are no study on project risk factors comparison between self-developing IS using programming language and adapting software packages already developed by software venders in IS project. This research can be differentiated from previous ones, because it was considered both point of project risk management and development methodology in IS project.

This research results implied meaningful messages to enterprise company to be planned IS projects and people who involved in IS projects. They should consider and need to prepare differently according to each development methodology for preventing project risks. It makes them reduce project risks in each case and complete successfully IS projects. Especially, if they have no experiences for implementing software packages, they can forecast the project risks and prepare them in advance.

Keywords: Project  Risk Management, Risk Factors, Software  Package