2008.08.11

가장 일반적인 프로젝트 관리실수 14 ②

Meridith Levinson | CIO
AP721D.JPG스탠디쉬 그룹이 조사한 바에 따르면, 29% IT 프로젝트만이 성공적으로 완수된다는 것은 놀랄만한 일이 아니다. 프로젝트관리 컨설턴트와 소프트웨어 공급업자들은 IT 부문에서 동일한 프로젝트 관리상의 실수가 반복적으로 나온다고 말한다. , IT 그룹은 표준 프로젝트관리 프로세스를 따르지 않고 있다. 프로젝트에서 일할 적합한 직원도 없다. 또한, 이들은 자신들의 프로젝트를 망칠 수 있는 위험에 대해 생각하지 않거나 이러한 위험을 완화시킬 방법도 결정하지 않고 있다. 결국, 뜨개실처럼 실수덩어리가 풀리고 있는 것이다.

IT
부문에서 저지르는 대부분의 프로젝트관리상의 실수는 결국 충분한 계획의 결핍 또는 커뮤니케이션 단절(프로젝트팀 간의 단절 또는 프로젝트팀과 프로젝트 스폰서 간의 단절)에서 나온다. 이러한 실수는 치명적일 수 있지만 피할 수도 있다. 이러한 대부분의 일반적인 프로젝트관리상의 실수를 프로젝트관리 벤더와 컨설턴트보다 더 잘 지적할 사람이 어디 있겠는가?

다음에 나오는 프로젝트 관리상 발생하는 가장 일반적인 실수 14개는 프로젝트가 잘못된 방향으로 가고 있는 점을 정확하게 지적할 수 있도록 도와주며, 이를 개선할 수 있도록 평가해준다. 이런 실수를 피하려고 하는 노력은 중요하다. 이를 통해, 프로젝트의 성공률이 증가할 뿐만 아니라 내부고객들의 만족도가 향상될 수 있고 , 조직내 IT의 주가가 올라가며, 비즈니스를 보다 경쟁력 있게 만들고 예산에 따라 제 시간에 완성되는 시스템을 통해 이득을 얻을 수도 있기 때문이다.

 

계획상의 실수

실수 No. 8: 프로젝트 영역을 규정하기 위한 시간을 들이지 않는다.


영향: 비즈니스 및 IT 부서가 프로젝트의 영역을 정직하게 규정하지 않으면, 프로젝트가 시트콤 “프렌즈(Friends)”의 배우 매튜 페리(Matthew Perry)와 같이 부풀려져 종결될 수 있다. 게다가, 프로젝트를 예산에 맞춰 제 시간에 완성하고 비즈니스의 기대치를 만족시켜야 하는 목표와 투명성이 부족하게 된다.

해결책: 콘도는 잘못 규정된 프로젝트를 고치려면, 비즈니스 실정과 문제를 해결하는 연습을 해야 한다고 충고했다.

실수No. 9: 프로젝트 간의 의존성을 깨닫는데 실패한다.

영향: 프로젝트는 독립적으로 진행되지 않는다. IT 프로젝트는 종종 동시에 진행되는 다른 프로젝트에 의존하고 있는데, 프로젝트 관리자들이 프로젝트 간의 이러한 의존성을 깨닫지 못하면(, 하나의 프로젝트에 배치된 직원들이 다른 프로젝트에 필요한 경우), 프로젝트를 진행시키는데 오랜 시간이 걸린다. 이러한 둔화현상은 프로젝트가 실패할 가능성이 높다.

해결책: 클라크는 프로젝트를 기획하는 동안 상호간의 의존성을 고려하라고 충고했다. 투자자들과 얘기하고 프로젝트를 도해(diagramming)함으로써 이러한 의존성을 노출시킬 수 있다.

실수No. 10: 머피의 법칙을 고려하지 않는다.

영향: 프로젝트를 진행하는 동안 각종 일들이 벌어지기 마련인데, 대비하지 못한 프로젝트 관리자는 놀라고 만다. 결국, 기대하지 못했던 혼란을IT 부문이 수습하는 동안 프로젝트는 궤도에서 벗어나게 된다.

글래스하우스 테크놀로지의 스캐넬은 다른 회사를 인수해 메인프레임을 새로운 데이터센터로 이동시켰던 경험을 상기했다. 당시 IT 그룹은 메임프레임을 다음 날 새로운 데이터센터로 옮기기 위해 토요일 내내 메인프레임 분해작업에 매달렸다. 일요일에 IT 직원들이 새로운 데이터센터로 메인프레임을 가져가는 도중에 이들은 게이 퍼레이드와 우연히 마주쳤고 , 퍼레이드로 인해 도로가 막히면서 데이터센터에 도착할 수 없었다. 결국, 원래 데이터센터로 다시 돌아와서 분해했던 메인프레임을 다시 조립해야 했다. , IT 직원들은 사전에 충분한 계획을 세우지 못했기 때문에 실제로 필요했던 일보다 더 많은 작업을 해야 했다.

해결책: 위험을 프로젝트 기획의 일부로 미리 산정해보라. 팀원들과 함께 프로젝트를 지체시키거나 다른 방향으로 이끌고 , 예산보다 많은 비용이 들게 하는 등의 다양한 변수를 브레인스토밍으로 토의해봐야 한다. 코펠만은 그리고 나서 이러한 위험성을 경감시킬 수 있는 방법을 찾아보라고 충고했다. 코펠만은 “다같이 앉아서 이러한 위험성에 대해 곰곰히 생각해 보면, 꽤 쓸만한 리스트가 만들어질 것이다”라며 “이렇게 연습하는 데는 오랜 시간이 걸리지 않으며, 심지어 프로젝트를 진행시키기 전에 프로젝트의 취약점을 이해하는데 큰 도움이 된다”고 덧붙였다.

실수No. 11: 관리 변화에 적은 시간을 투자한다.

영향: 사용자들이 새로운 기술을 받아들이지 않으면 새로운 가능성 있는 IT 역량에 쏟아 부은 돈과 힘든 일은 언제라도 헛된 것으로 돌아갈 수 있다.

해결책: 메티에의 클라크는 프로젝트를 계획할 때, 충분한 시간을 갖고 프로젝트 방해 요소가 어디서 어떻게 나올지 고려해야 한다고 말했다. 콘도는 새 역량으로 일에 영향을 줄 수 있는 투자자를 식별하라면서, 변경사항을 자신의 프로세스와 작업에 어떻게 적용할지 계획을 세우라고 충고했다. 모든 변화가 부정적인 것은 아니다.

실수No. 12: 프로젝트 일정이 미완성으로 끝난다.

영향: 프로젝트 팀원들이 기한이 언제인지 모르면, 프로젝트를 제 시간에 완성하는데 문제가 발생한다.

해결책: 클라크는 프로젝트 일정을 맞추기 위한 빠른 방법은 프로젝트를 완성하는 것(, 문제해결, 필수사항 확보, 테스트 및 이행)과 연관된 모든 활동사항을 결정하고 , 프로젝트의 최종기한을 바탕으로 예정된 날짜를 상기 활동사항에 첨부해 놓는 것이라고 말한다. 또한, 일정을 짜는 데 있어 프로젝트관리 소프트웨어가 도움이 될 수 있다.

커뮤니케이션상의 문제

실수No. 13: IT 부서는 비합리적인 최종기한을 거절하지 않는다.

영향: 기한을 제때 맞추지 못해, IT 부서가 프로젝트를 제 시간에 완성하지 못한다는 평가를 받는다.

클라크는 IT 부문이 CEO가 설정한 프로젝트 기한을 맞추기 위해 일을 서둘러 진행하지만, 부속물과 계획 등을 함부로 변경하면 더 많은 문제가 파생되어 제 시간에 프로젝트를 완성하는 것이 더 어렵게 된다고 말했다.

해결책: 클라크는 IT 담당자가 최종기한을 지키기 위해 비용과 자원 면에서 어떤 것이 진행될 지를 CEO에게 설명해야 하며, 비용과, 범위, 일정 중에서 CEO가 직접 선택하도록 해야 한다고 충고했다.

실수No. 14: 프로젝트 스폰서 및 투자자들과의 충분한 의사소통이 부족하다.

영향: IT 부서가 필요한 필수사항을 전달하는 데 실패한다.


해결책:콘도는 프로젝트 관련자들과의 커뮤니케이션이 이뤄져야 한다고 충고했다. 콘도는 시스템의 기능과 스펙이 기술된 복잡한 구성된 스프레드시트를 비즈니스 관계자들에게 건네줄 때, IT 담당자가 프로젝트의 영역 또는 시스템상의 필수사항에 대한 오해를 불러일으킨다고 보고 있다. 비즈니스 관계자들은 이렇게 자세히 기록된 기술문서를 살펴볼 시간이 없기 때문에, 이들은 그냥 무시하는 것이다.

콘도는 “한쪽에서는 의사를 전달하고 있지만 다른 한쪽에서는 그 언어를 이해하지 못한다”라며, IT 부문은 좌절하면서, 이미 설명한 내용인데 어떻게 이것이 관계자들이 원하는 것이 아닐 수 있는가 의문을 갖는다라고 말했다. (사용자와 IT 간의 통신망으로써 비즈니스 분석가들이 중요한 역할을 수행한다).

콘도는 비즈니스 측면에서 프로젝트에 연관되어 있거나 영향을 받는 모든 투자자들에게 설계에서부터 공개까지, 프로젝트 전반에 관한 수준 높은 개요를 제공할 것을 권한다. 이때, 비즈니스 관계자들과의 상호작용을 요구하는 활동사항을 이 개요 안에서 강조해야 하며, 왜 이들이 필요한 지에 대한 설명 또한 포함되어 있어야 한다.

일반적으로 IT 부서는 프로젝트를 이행하는 것과 연관된 각 단계에 대해 비즈니스 관계자들을 교육시키는데 더 많은 노력을 기울여야 한다. 콘도는 “무엇이 필요한지, 정말로 하고자 하는 것이 무엇인지에 대해 개방적인 방식으로 얘기하고 프로세스에 유동성을 부여할 수 있다면, 예산과 프로젝트 영역에 대해서도 얘기할 수 있게 된다. 따라서, 예산이 초과되어도 이것이 꼭 실패를 의미하지는 않는다”라고 말했다.

콘도의 회사는 한때 금융시스템을 배치하던 고객과 일한 적이 있었는데, 이 고객의 회사직원들은 대규모 시스템실행작업과 연관되어 일한 적이 전혀 없었다고 한다. 시스템설계가 완성되고 인텔리링크가 테스트계획을 개시할 때, 인텔리링크는 직원들에게 왜 테스트작업이 중요한지를 설명했다.

콘도는 “서로 다른 종류의 테스트에 대해 직원들에게 설명하면서 이들이 관련될 필요가 있는 것과 그렇지 않은 작업에 대해 설명했다. 또한, 사용자입력이 왜 필요한지, 어떤 종류의 입력이 필요한지, 그리고 시간은 얼마나 걸리는지에 관해 얘기했다”고 말했다. 더불어 “이를 통해 테스트작업이 왜 그렇게 오래 걸리는지에 관해 사람들에게 알려줄 수 있었다”고 덧붙였다.


2008.08.11

가장 일반적인 프로젝트 관리실수 14 ②

Meridith Levinson | CIO
AP721D.JPG스탠디쉬 그룹이 조사한 바에 따르면, 29% IT 프로젝트만이 성공적으로 완수된다는 것은 놀랄만한 일이 아니다. 프로젝트관리 컨설턴트와 소프트웨어 공급업자들은 IT 부문에서 동일한 프로젝트 관리상의 실수가 반복적으로 나온다고 말한다. , IT 그룹은 표준 프로젝트관리 프로세스를 따르지 않고 있다. 프로젝트에서 일할 적합한 직원도 없다. 또한, 이들은 자신들의 프로젝트를 망칠 수 있는 위험에 대해 생각하지 않거나 이러한 위험을 완화시킬 방법도 결정하지 않고 있다. 결국, 뜨개실처럼 실수덩어리가 풀리고 있는 것이다.

IT
부문에서 저지르는 대부분의 프로젝트관리상의 실수는 결국 충분한 계획의 결핍 또는 커뮤니케이션 단절(프로젝트팀 간의 단절 또는 프로젝트팀과 프로젝트 스폰서 간의 단절)에서 나온다. 이러한 실수는 치명적일 수 있지만 피할 수도 있다. 이러한 대부분의 일반적인 프로젝트관리상의 실수를 프로젝트관리 벤더와 컨설턴트보다 더 잘 지적할 사람이 어디 있겠는가?

다음에 나오는 프로젝트 관리상 발생하는 가장 일반적인 실수 14개는 프로젝트가 잘못된 방향으로 가고 있는 점을 정확하게 지적할 수 있도록 도와주며, 이를 개선할 수 있도록 평가해준다. 이런 실수를 피하려고 하는 노력은 중요하다. 이를 통해, 프로젝트의 성공률이 증가할 뿐만 아니라 내부고객들의 만족도가 향상될 수 있고 , 조직내 IT의 주가가 올라가며, 비즈니스를 보다 경쟁력 있게 만들고 예산에 따라 제 시간에 완성되는 시스템을 통해 이득을 얻을 수도 있기 때문이다.

 

계획상의 실수

실수 No. 8: 프로젝트 영역을 규정하기 위한 시간을 들이지 않는다.


영향: 비즈니스 및 IT 부서가 프로젝트의 영역을 정직하게 규정하지 않으면, 프로젝트가 시트콤 “프렌즈(Friends)”의 배우 매튜 페리(Matthew Perry)와 같이 부풀려져 종결될 수 있다. 게다가, 프로젝트를 예산에 맞춰 제 시간에 완성하고 비즈니스의 기대치를 만족시켜야 하는 목표와 투명성이 부족하게 된다.

해결책: 콘도는 잘못 규정된 프로젝트를 고치려면, 비즈니스 실정과 문제를 해결하는 연습을 해야 한다고 충고했다.

실수No. 9: 프로젝트 간의 의존성을 깨닫는데 실패한다.

영향: 프로젝트는 독립적으로 진행되지 않는다. IT 프로젝트는 종종 동시에 진행되는 다른 프로젝트에 의존하고 있는데, 프로젝트 관리자들이 프로젝트 간의 이러한 의존성을 깨닫지 못하면(, 하나의 프로젝트에 배치된 직원들이 다른 프로젝트에 필요한 경우), 프로젝트를 진행시키는데 오랜 시간이 걸린다. 이러한 둔화현상은 프로젝트가 실패할 가능성이 높다.

해결책: 클라크는 프로젝트를 기획하는 동안 상호간의 의존성을 고려하라고 충고했다. 투자자들과 얘기하고 프로젝트를 도해(diagramming)함으로써 이러한 의존성을 노출시킬 수 있다.

실수No. 10: 머피의 법칙을 고려하지 않는다.

영향: 프로젝트를 진행하는 동안 각종 일들이 벌어지기 마련인데, 대비하지 못한 프로젝트 관리자는 놀라고 만다. 결국, 기대하지 못했던 혼란을IT 부문이 수습하는 동안 프로젝트는 궤도에서 벗어나게 된다.

글래스하우스 테크놀로지의 스캐넬은 다른 회사를 인수해 메인프레임을 새로운 데이터센터로 이동시켰던 경험을 상기했다. 당시 IT 그룹은 메임프레임을 다음 날 새로운 데이터센터로 옮기기 위해 토요일 내내 메인프레임 분해작업에 매달렸다. 일요일에 IT 직원들이 새로운 데이터센터로 메인프레임을 가져가는 도중에 이들은 게이 퍼레이드와 우연히 마주쳤고 , 퍼레이드로 인해 도로가 막히면서 데이터센터에 도착할 수 없었다. 결국, 원래 데이터센터로 다시 돌아와서 분해했던 메인프레임을 다시 조립해야 했다. , IT 직원들은 사전에 충분한 계획을 세우지 못했기 때문에 실제로 필요했던 일보다 더 많은 작업을 해야 했다.

해결책: 위험을 프로젝트 기획의 일부로 미리 산정해보라. 팀원들과 함께 프로젝트를 지체시키거나 다른 방향으로 이끌고 , 예산보다 많은 비용이 들게 하는 등의 다양한 변수를 브레인스토밍으로 토의해봐야 한다. 코펠만은 그리고 나서 이러한 위험성을 경감시킬 수 있는 방법을 찾아보라고 충고했다. 코펠만은 “다같이 앉아서 이러한 위험성에 대해 곰곰히 생각해 보면, 꽤 쓸만한 리스트가 만들어질 것이다”라며 “이렇게 연습하는 데는 오랜 시간이 걸리지 않으며, 심지어 프로젝트를 진행시키기 전에 프로젝트의 취약점을 이해하는데 큰 도움이 된다”고 덧붙였다.

실수No. 11: 관리 변화에 적은 시간을 투자한다.

영향: 사용자들이 새로운 기술을 받아들이지 않으면 새로운 가능성 있는 IT 역량에 쏟아 부은 돈과 힘든 일은 언제라도 헛된 것으로 돌아갈 수 있다.

해결책: 메티에의 클라크는 프로젝트를 계획할 때, 충분한 시간을 갖고 프로젝트 방해 요소가 어디서 어떻게 나올지 고려해야 한다고 말했다. 콘도는 새 역량으로 일에 영향을 줄 수 있는 투자자를 식별하라면서, 변경사항을 자신의 프로세스와 작업에 어떻게 적용할지 계획을 세우라고 충고했다. 모든 변화가 부정적인 것은 아니다.

실수No. 12: 프로젝트 일정이 미완성으로 끝난다.

영향: 프로젝트 팀원들이 기한이 언제인지 모르면, 프로젝트를 제 시간에 완성하는데 문제가 발생한다.

해결책: 클라크는 프로젝트 일정을 맞추기 위한 빠른 방법은 프로젝트를 완성하는 것(, 문제해결, 필수사항 확보, 테스트 및 이행)과 연관된 모든 활동사항을 결정하고 , 프로젝트의 최종기한을 바탕으로 예정된 날짜를 상기 활동사항에 첨부해 놓는 것이라고 말한다. 또한, 일정을 짜는 데 있어 프로젝트관리 소프트웨어가 도움이 될 수 있다.

커뮤니케이션상의 문제

실수No. 13: IT 부서는 비합리적인 최종기한을 거절하지 않는다.

영향: 기한을 제때 맞추지 못해, IT 부서가 프로젝트를 제 시간에 완성하지 못한다는 평가를 받는다.

클라크는 IT 부문이 CEO가 설정한 프로젝트 기한을 맞추기 위해 일을 서둘러 진행하지만, 부속물과 계획 등을 함부로 변경하면 더 많은 문제가 파생되어 제 시간에 프로젝트를 완성하는 것이 더 어렵게 된다고 말했다.

해결책: 클라크는 IT 담당자가 최종기한을 지키기 위해 비용과 자원 면에서 어떤 것이 진행될 지를 CEO에게 설명해야 하며, 비용과, 범위, 일정 중에서 CEO가 직접 선택하도록 해야 한다고 충고했다.

실수No. 14: 프로젝트 스폰서 및 투자자들과의 충분한 의사소통이 부족하다.

영향: IT 부서가 필요한 필수사항을 전달하는 데 실패한다.


해결책:콘도는 프로젝트 관련자들과의 커뮤니케이션이 이뤄져야 한다고 충고했다. 콘도는 시스템의 기능과 스펙이 기술된 복잡한 구성된 스프레드시트를 비즈니스 관계자들에게 건네줄 때, IT 담당자가 프로젝트의 영역 또는 시스템상의 필수사항에 대한 오해를 불러일으킨다고 보고 있다. 비즈니스 관계자들은 이렇게 자세히 기록된 기술문서를 살펴볼 시간이 없기 때문에, 이들은 그냥 무시하는 것이다.

콘도는 “한쪽에서는 의사를 전달하고 있지만 다른 한쪽에서는 그 언어를 이해하지 못한다”라며, IT 부문은 좌절하면서, 이미 설명한 내용인데 어떻게 이것이 관계자들이 원하는 것이 아닐 수 있는가 의문을 갖는다라고 말했다. (사용자와 IT 간의 통신망으로써 비즈니스 분석가들이 중요한 역할을 수행한다).

콘도는 비즈니스 측면에서 프로젝트에 연관되어 있거나 영향을 받는 모든 투자자들에게 설계에서부터 공개까지, 프로젝트 전반에 관한 수준 높은 개요를 제공할 것을 권한다. 이때, 비즈니스 관계자들과의 상호작용을 요구하는 활동사항을 이 개요 안에서 강조해야 하며, 왜 이들이 필요한 지에 대한 설명 또한 포함되어 있어야 한다.

일반적으로 IT 부서는 프로젝트를 이행하는 것과 연관된 각 단계에 대해 비즈니스 관계자들을 교육시키는데 더 많은 노력을 기울여야 한다. 콘도는 “무엇이 필요한지, 정말로 하고자 하는 것이 무엇인지에 대해 개방적인 방식으로 얘기하고 프로세스에 유동성을 부여할 수 있다면, 예산과 프로젝트 영역에 대해서도 얘기할 수 있게 된다. 따라서, 예산이 초과되어도 이것이 꼭 실패를 의미하지는 않는다”라고 말했다.

콘도의 회사는 한때 금융시스템을 배치하던 고객과 일한 적이 있었는데, 이 고객의 회사직원들은 대규모 시스템실행작업과 연관되어 일한 적이 전혀 없었다고 한다. 시스템설계가 완성되고 인텔리링크가 테스트계획을 개시할 때, 인텔리링크는 직원들에게 왜 테스트작업이 중요한지를 설명했다.

콘도는 “서로 다른 종류의 테스트에 대해 직원들에게 설명하면서 이들이 관련될 필요가 있는 것과 그렇지 않은 작업에 대해 설명했다. 또한, 사용자입력이 왜 필요한지, 어떤 종류의 입력이 필요한지, 그리고 시간은 얼마나 걸리는지에 관해 얘기했다”고 말했다. 더불어 “이를 통해 테스트작업이 왜 그렇게 오래 걸리는지에 관해 사람들에게 알려줄 수 있었다”고 덧붙였다.


X