목차
프로젝트 계획단계
문제의 정의 (Defining the Problem)
RMO 사례에서의 문제정의
프로젝트 일정계획의 수립
PERT/CPM 차트 작성
프로젝트 가능성 확인
경제적 가능성
개발비용
시스템 운영상 필요한 비용의 출처
이익의 출처
경제성 산정
보이지 않는 요소들
자금조달방법
조직/문화적 가능성
기술적 가능성
일정가능성
자원가능성
가능성 분석
프로젝트 팀구성
문제의 정의 (Defining the Problem)
RMO 사례에서의 문제정의
프로젝트 일정계획의 수립
PERT/CPM 차트 작성
프로젝트 가능성 확인
경제적 가능성
개발비용
시스템 운영상 필요한 비용의 출처
이익의 출처
경제성 산정
보이지 않는 요소들
자금조달방법
조직/문화적 가능성
기술적 가능성
일정가능성
자원가능성
가능성 분석
프로젝트 팀구성
본문내용
전문가를 분배하는 것은 항상 문제가 된다. 어떤 복잡한 프로젝트는 시간초과와 일정의 연장등의 요소가 잠재되어 있다. 이러한 위험요소들을 규명하기는 힘들지만, 적극적인 노력으로 이러한 요소들의 영역은 알 수 있게 된다. 장기 프로젝트는 특히 이러한 일정초과, 자원분배와 같은 어려움과 많이 봉착하게 된다. 자체적인 자원조달이 불가능할 때의 해결책은 임시 계획을 포함할 수 있다.
자원가능성
마지막으로, 프로젝트 운영팀은 반드시 프로젝트를 위한 자원의 사용가능성을 확인해야 한다. 가장 중요한 자원은 팀의 멤버이다. 프로젝트 개발은 System Analyst, 시스템 기술자, 사용자들의 참여를 필요로 한다. 이러한 필요인원을 제때에 프로젝트에 투입되지 못하는 경우도 발생한다. 또한 어떤 경우에는 프로젝트에 필요한 기술을 갖지못한 사람이 투입될 수도 있다. 프로젝트팀이 재 기능을 발휘할 때에는 구성원의 일부가 이탈할 수 있다는 문제도 발생한다. 이러한 문제는 다른 회사의 프로젝트 개발팀에 의해 일어날 수도 있고, 회사 내부에서 더욱 중요한 프로젝트가 발생함에 따라서 일어날 수도 있다. 프로젝트 책임자는 이러한 가능성에 대해 고려하길 꺼려하지만, 기술을 가진 사람들은 지원이 부족할때에는, 때때로 프로젝트에서 이탈하기도 한다
프로젝트 개발에 필요한 또 다른 자원으로는 적절한 컴퓨터 자원, 쾌적한 설비, 그리고 필요자원이다. 이러한 것들은 대부분 가능하지만 만약 이러한 자원들의 사용에 지연이 있게되면 일정은 영향을 받게 된다.
가능성 분석
이전의 가능성 분석들은 모두 프로젝트가 가능성 있다는 가정을 했다. 그러나 모든 프로젝트가 가능성 있는 것은 아니다. 프로젝트의 실현을 위해서는 모든 가능성 테스트를 통과해야만 한다. 만약 어떠한 한 가지 가능성이라도 불확실 하다면, 그 프로젝트는 착수해서는 안된다. 큰 실패 위험성을 내재한 프로젝트의 실현을 위한 실용적인 대안은 한마디로 아무것도 아니게 된다. (적어도 현재에는 그렇다는 뜻이다. 왜냐하면 기술적 제약, 높은 비용, 부적절한 전문가로 인해 불가능한 프로젝트는 미래에는 가능하게 될 수도 있기 때문이다.) 프로젝트 책임자에게 있어서 프로젝트가 불가능하고 절대 수행되어서는 안 된다는 결론을 내리는 것은 항상 어려운 일임에 틀림이 없다. 그러나 그러한 프로젝트의 추진을 위한 대안의 시작은 회사와 그 밖의 관련된 모든 사람에게 손해를 입힌다는 것은 예정되어 있다.
이러한 5가지의 영역에 대한 가능성의 평가는 프로젝트 기획 단계에서 굉장히 중요한 부분이다. 이 분석과정에서 알아내야 하는것은 ‘이 프로젝트는 여전히 수행되어져야 하는가?’하는 것이다.
프로젝트 팀구성
프로젝트 책임자에게는 프로젝트 팀 멤버를 구성해야 하는 책임이 떨어진다. 인적자원 관리는 프로젝트에서의 적절한 인재발굴, 팀 구성, 관리를 포함하고 있다. 이 활동은 다음의
5가지 업무를 포함한다.
- 프로젝트를 위해 자원계획을 작성
- 구체적 기술인력의 규명과 요청
- 구체적 사용자 규명과 요청
- 프로젝트 팀을 사업팀으로
- 사전 트레이닝의 구성과 팀 설립연습
프로젝트 일정에서 규명되었던 일들에 기초하여, 프로젝트 책임자는 자원 계획을 구체적으로 계획 할 수 있어야 한다. 실제로 일정과 자원 요구사항은 대개 동시적으로 작성된다. 프로젝트 책임자가 Microsoft project와 같은 도구를 사용한다면, 각 일을 위한 자원은 전체 일정 중의 한 부분이다. 계획 수립에서 프로젝트 책임자는 (1) 자원은 필요할 때 사용가능하지는 않다는 것과 (2) 프로젝트를 위한 사람을 위해서는 시간이 필요하다는 것을 깨달아야 한다.
계획수립 후, 프로젝트 책임자는 구체적으로 필요한 사람들을 규명하고 그들이 팀의 구성원이 되도록 요청을 할 수 있다. 일반적으로 기술 스텝과 사용자 스텝 두 부분으로 팀 멤버를 위한 자원을 나눌 수 있다. 기술 스텝은 System Analyst, 프로그래머 분석가, 네트워크 전문가, 그리고 다른 기술자들이다. 기술 스텝은 프로젝트에서 프로젝트로의 이동을 기대하고 변화를 평범하게 여겼다. 프로젝트 매니저는 필요한 자원을 규명하고 일정을 수립하기 위하여 정보시스템운영자나 부사장을 만난다. 몇 가지 예에서, 추가적으로 기술 전문가의 고용이 필요할 것이고 그래서 인적자원 부문이 팀에 포함될 필요가 생긴다. 기술전문가 인력을 팀을 위해 찾는 것은 기본적인 방법이지만, 필요한 팀 구성원 모두를 임명하는 것은 얼마간의 시간이 걸릴 수 있다.
사용자스텝이란 사용자 커뮤니티로부터 나온 사람들을 팀을 위해 영입한다. 때때로 그 사용자들을 전업으로 고용하는 것은 힘들다. 프로젝트팀을 위해 임명되는 것은 사용자부문이나 그룹에 있는 사람들처럼 전문성을 띤 직업의 종류가 아니다. 그러나 만약 몇 명의 전업직원이 사용자 커뮤니티를 대변하고 가까운 관계를 나타낸다면 프로젝트는 좀더 쉽게 진행될 수 있다. 프로젝트 실패의 원인을 되짚어볼 때, 사용자나 프로젝트팀의 구성원들과 친밀한 관계를 유지하는 것은 프로젝트 성공의 기회를 좀더 높여준다.
작은 프로젝트에서는, 프로젝트의 구성원들이 모두 일을 함께 한다. 그러나 4-5명 이상의 프로젝트팀은 좀더 작은 작업그룹형태로 나뉘게 되고, 각 그룹에 할당된 일들을 조정하게 될 리더를 가지게 된다. 팀을 작업그룹으로 나누고, 각 그룹별 리더를 선별하는 데에 대한 책임은 프로젝트 책임자가 지게 된다.
마지막으로, 트레이닝과 팀 구성력 증강을 위한 연습이 계획된다. 트레이닝은 새 DB나 새 프로그래밍 언어 등과 같이 새로운 기술이 사용되는 모든 곳에서 이루어진다. 그렇지 않은 경우에는 사용된 도구와 기법에 익숙치 못한 팀 구성원들에게는 개인 트레이닝이 필요하다. 프로젝트 책임자는 반드시 기술인력과 사용자 모두를 위한 트레이닝을 기획해야 한다. 팀웍을 위한 연습은 특히 한번도 손발을 맞추어 보지 못한 구성원들을 위해 중요하다. 기술인력과 사용자 구성원들의 적절한 통합은 효율적인 팀과 작업그룹들을 위해 굉장히 중요한 고려사항이다. 이 활동이 끝나게 되면 ‘자원이 가용하고 훈련 되어있으며, 프로젝트 수행준비가 모두 되었는가’라는 질문에 답을 할 수 있어야 한다.
자원가능성
마지막으로, 프로젝트 운영팀은 반드시 프로젝트를 위한 자원의 사용가능성을 확인해야 한다. 가장 중요한 자원은 팀의 멤버이다. 프로젝트 개발은 System Analyst, 시스템 기술자, 사용자들의 참여를 필요로 한다. 이러한 필요인원을 제때에 프로젝트에 투입되지 못하는 경우도 발생한다. 또한 어떤 경우에는 프로젝트에 필요한 기술을 갖지못한 사람이 투입될 수도 있다. 프로젝트팀이 재 기능을 발휘할 때에는 구성원의 일부가 이탈할 수 있다는 문제도 발생한다. 이러한 문제는 다른 회사의 프로젝트 개발팀에 의해 일어날 수도 있고, 회사 내부에서 더욱 중요한 프로젝트가 발생함에 따라서 일어날 수도 있다. 프로젝트 책임자는 이러한 가능성에 대해 고려하길 꺼려하지만, 기술을 가진 사람들은 지원이 부족할때에는, 때때로 프로젝트에서 이탈하기도 한다
프로젝트 개발에 필요한 또 다른 자원으로는 적절한 컴퓨터 자원, 쾌적한 설비, 그리고 필요자원이다. 이러한 것들은 대부분 가능하지만 만약 이러한 자원들의 사용에 지연이 있게되면 일정은 영향을 받게 된다.
가능성 분석
이전의 가능성 분석들은 모두 프로젝트가 가능성 있다는 가정을 했다. 그러나 모든 프로젝트가 가능성 있는 것은 아니다. 프로젝트의 실현을 위해서는 모든 가능성 테스트를 통과해야만 한다. 만약 어떠한 한 가지 가능성이라도 불확실 하다면, 그 프로젝트는 착수해서는 안된다. 큰 실패 위험성을 내재한 프로젝트의 실현을 위한 실용적인 대안은 한마디로 아무것도 아니게 된다. (적어도 현재에는 그렇다는 뜻이다. 왜냐하면 기술적 제약, 높은 비용, 부적절한 전문가로 인해 불가능한 프로젝트는 미래에는 가능하게 될 수도 있기 때문이다.) 프로젝트 책임자에게 있어서 프로젝트가 불가능하고 절대 수행되어서는 안 된다는 결론을 내리는 것은 항상 어려운 일임에 틀림이 없다. 그러나 그러한 프로젝트의 추진을 위한 대안의 시작은 회사와 그 밖의 관련된 모든 사람에게 손해를 입힌다는 것은 예정되어 있다.
이러한 5가지의 영역에 대한 가능성의 평가는 프로젝트 기획 단계에서 굉장히 중요한 부분이다. 이 분석과정에서 알아내야 하는것은 ‘이 프로젝트는 여전히 수행되어져야 하는가?’하는 것이다.
프로젝트 팀구성
프로젝트 책임자에게는 프로젝트 팀 멤버를 구성해야 하는 책임이 떨어진다. 인적자원 관리는 프로젝트에서의 적절한 인재발굴, 팀 구성, 관리를 포함하고 있다. 이 활동은 다음의
5가지 업무를 포함한다.
- 프로젝트를 위해 자원계획을 작성
- 구체적 기술인력의 규명과 요청
- 구체적 사용자 규명과 요청
- 프로젝트 팀을 사업팀으로
- 사전 트레이닝의 구성과 팀 설립연습
프로젝트 일정에서 규명되었던 일들에 기초하여, 프로젝트 책임자는 자원 계획을 구체적으로 계획 할 수 있어야 한다. 실제로 일정과 자원 요구사항은 대개 동시적으로 작성된다. 프로젝트 책임자가 Microsoft project와 같은 도구를 사용한다면, 각 일을 위한 자원은 전체 일정 중의 한 부분이다. 계획 수립에서 프로젝트 책임자는 (1) 자원은 필요할 때 사용가능하지는 않다는 것과 (2) 프로젝트를 위한 사람을 위해서는 시간이 필요하다는 것을 깨달아야 한다.
계획수립 후, 프로젝트 책임자는 구체적으로 필요한 사람들을 규명하고 그들이 팀의 구성원이 되도록 요청을 할 수 있다. 일반적으로 기술 스텝과 사용자 스텝 두 부분으로 팀 멤버를 위한 자원을 나눌 수 있다. 기술 스텝은 System Analyst, 프로그래머 분석가, 네트워크 전문가, 그리고 다른 기술자들이다. 기술 스텝은 프로젝트에서 프로젝트로의 이동을 기대하고 변화를 평범하게 여겼다. 프로젝트 매니저는 필요한 자원을 규명하고 일정을 수립하기 위하여 정보시스템운영자나 부사장을 만난다. 몇 가지 예에서, 추가적으로 기술 전문가의 고용이 필요할 것이고 그래서 인적자원 부문이 팀에 포함될 필요가 생긴다. 기술전문가 인력을 팀을 위해 찾는 것은 기본적인 방법이지만, 필요한 팀 구성원 모두를 임명하는 것은 얼마간의 시간이 걸릴 수 있다.
사용자스텝이란 사용자 커뮤니티로부터 나온 사람들을 팀을 위해 영입한다. 때때로 그 사용자들을 전업으로 고용하는 것은 힘들다. 프로젝트팀을 위해 임명되는 것은 사용자부문이나 그룹에 있는 사람들처럼 전문성을 띤 직업의 종류가 아니다. 그러나 만약 몇 명의 전업직원이 사용자 커뮤니티를 대변하고 가까운 관계를 나타낸다면 프로젝트는 좀더 쉽게 진행될 수 있다. 프로젝트 실패의 원인을 되짚어볼 때, 사용자나 프로젝트팀의 구성원들과 친밀한 관계를 유지하는 것은 프로젝트 성공의 기회를 좀더 높여준다.
작은 프로젝트에서는, 프로젝트의 구성원들이 모두 일을 함께 한다. 그러나 4-5명 이상의 프로젝트팀은 좀더 작은 작업그룹형태로 나뉘게 되고, 각 그룹에 할당된 일들을 조정하게 될 리더를 가지게 된다. 팀을 작업그룹으로 나누고, 각 그룹별 리더를 선별하는 데에 대한 책임은 프로젝트 책임자가 지게 된다.
마지막으로, 트레이닝과 팀 구성력 증강을 위한 연습이 계획된다. 트레이닝은 새 DB나 새 프로그래밍 언어 등과 같이 새로운 기술이 사용되는 모든 곳에서 이루어진다. 그렇지 않은 경우에는 사용된 도구와 기법에 익숙치 못한 팀 구성원들에게는 개인 트레이닝이 필요하다. 프로젝트 책임자는 반드시 기술인력과 사용자 모두를 위한 트레이닝을 기획해야 한다. 팀웍을 위한 연습은 특히 한번도 손발을 맞추어 보지 못한 구성원들을 위해 중요하다. 기술인력과 사용자 구성원들의 적절한 통합은 효율적인 팀과 작업그룹들을 위해 굉장히 중요한 고려사항이다. 이 활동이 끝나게 되면 ‘자원이 가용하고 훈련 되어있으며, 프로젝트 수행준비가 모두 되었는가’라는 질문에 답을 할 수 있어야 한다.
추천자료
환경경영시스템의 대두배경과 환경경영시스템 업종별 규모별 인증현황
HACCP 시스템과 ISO22000 시스템과의 비교분석
[IT와경영정보시스템]컴퓨터 시스템의 하드웨어 직렬처리 및 병렬처리방식 분석과 소프트웨어...
경영정보시스템(MIS)의 분석 및 정보시스템 도입의 국내외 성공사례와 실패사례
BI시스템, BI시스템적용사례, 도입배경및특징, 산업별BI적용사례, Business Intelligence
[중소기업ERP]중소기업 전사적 자원관리시스템(중소기업ERP)의 의의, 중소기업 전사적 자원관...
[IT와경영정보시스템 공통] 정보시스템에 BPR(Business Peocess Reengineering)을 적용하는 ...
Sonic을 통해 알아본 정보시스템 이용 사례,정보시스템,정보시스템사례
[기업 혁신][기업][기술][SI][평가시스템]기업 기술 혁신, 기업 SI(시스템통합) 혁신, 기업 ...
대한통운의 자동통합배차시스템,CJ GLS 통합배차시스템,첨단물류기술과 물류공동화,3PL(3자 ...
소개글