프로젝트가 실패하는 10가지 이유(3)

프로젝트가 실패하는 10가지 이유(3)

Frank Winters

 

논의의 실마리가 활발하게 이어지고 있다. 2003년 11월부터 시작한 시리즈의 첫 번째 기사가 실린 이래, 우리는 프로젝트 관리 중앙 게시판에서 매우 활발한 토론을 가졌다. 여기에 기여한 모든 참가자 및 독자에게 감사드린다.

 

테마 가운데 하나는 프로젝트 관리자만 전적으로 비난하는 것을 피하자는 것이었다. 다른 테마는 목표설정과 변화관리의 중요성이었다. 게시한 사람 가운데 몇 사람은 상위 10목록을 지지했지만, 어떤 이는 자신의 목록을 제공했다. 이 시점에서 상위 30모록도 만들 수 있지 않을까 생각한다.

 

PM을 옹호하려고, 몇몇 사람들은 우리가 관심을 가져야 할 프로젝트의 책임자 그리고 상급 관리자에게 용기, 참여 그리고 위임이 부족했었다고 꼬집었다. 또한 상급 관리자가 지원 가능하고 프로젝트에 친숙한 환경을 만들어야 하는 더 나은 일을 할 필요가 있다고 언급했다.

프로젝트 책임자와 관련이 있지만 명백하게 모순된 견해는 이들이 프로젝트의 수명기간 내내 새로운 아이디어를 끊임없이 끼워 넣는데, 그것이 혼란스런 상황을 만든 원인이 되었다는 것이다. 설상가상으로 이러한 의견들이 자질이 부족한 사람들 그리고 심지어는 믿을 수 없는 사람들에 의해 제기되어 더욱 혼란스럽게 만들었다. 같은 맥락으로(프로젝트 책임자와 상급 관리자에 대한 혹평), 몇몇 게시자 가운데는 비현실적인 기대를 설정하여 프로젝트를 성공시키지 못한 경우도 있다고 말했다.

 

학문적인 지식은 부적절한데, 기술적인 스킬에 너무 집중한다고 몇 사람이 제기했다. 초창기에 논의를 시작하면서 성공을 정의해야 한다는 지적이 몇 사람에 의해 제기되었다. 최근에 프로젝트 관리자에 관해 배운 대로 행동하지 않는다는 것이 포인트였다. 최근에 한 게시자가 그러한 취지로 최근의 GanttHead기사를 지적했다(Mark Mullaly의 “자격 취득 후 현실을 보라 : 이제부터는 어떻게 할 것인가?”).

 

전문 교육에서 배운 도구와 기법을 사용하지 않을 경우, 성공을 기대할 수 있는가? “우리는 처치 곤란한 세부 작업 분류 구조는 필요없다”라는 자세는 성공의 레시피가 아니지만, “카우보이”를 보기 좋아하면 보는 것도 재미있을 것이다.

 

대다수의 GanttHead 회원이 논평한 바에 따르면 프로젝트 실패의 원인은 사고와 논의를 위한 중요한 토픽이다. 몇몇 사람은 그것을 항상 생각한다고 말한다. 아마도 많은 PM이 실패의 원인을 많이 생각할 것이다: 그것은 당혹스런 실패로 빨려 들어가는 것을 두려워하고 그러한 운명을 피하기 위한 방법을 잘 모르기 때문이다.

 

지난 해 9월에 PMI가 발간한 PM Network에서, Michael Hatfield의 “실패를 인식하기”라는 제목의 변화 시발점 칼럼은 다음과 같이 말했다. “지금 어떤 의미에서, 프로젝트 관리 실무자들인 우리는 다달이 힘들게 일하고 있는 사람과 동료들에게 감사의 빚을 지고 있다[Titanic, Hindenberg그리고 피사의 사탑 “프로젝트”의 PM을 가리킨다]. 실패가 확실하다는데 대한 두려움 때문에 공식적인 프로젝트 관리 기법을 사용하도록 많은 유인책을 제공한다. “그런 다음 그는 가장 공공연하게 엉망이 된 프로젝트에 대해 PMI가 상을 줄 것을 제안했다. 이것은 아마도 마이클이 과거에 가졌던 백일몽에 기인할지도 모른다.

 

계속해서 논의의 실마리를 이어가겠으며, 이번에는 “독자는 무엇 때문에 공식적인 프로젝트 관리기법을 사용하거나 또는 못하는가?”라는 새로운 테마를 추가했다. 그것은 실패가 두려워서인가, 직업적 긍지 때문인가, 심도 있는 훈련 때문인가, 동료의 압력 때문인가, 회사의 문화 때문인가 아니면 전혀 다른 무엇 때문인가?

 

기대와 범위 관리

기대를 설정한 다음 그것을 관리하는 것은 프로젝트의 핵심 성공요인이다. PMBOK가이드를 이뇽하면 : “범위를 적절하게 정의하는 것이 프로젝트 성공에 중요하다.”

 

기대의 충족을 유도하고 이해한 범위 전체를 인도하는 것은 프로젝트 관리의 주요 기능이다. 기대와 범위를 설정하고 관리할 때 많은 문제가 너무 비공식적으로, 또는 역으로 너무 공식적으로 일어난다.

 

다시 말해, 기대가 해석하기에 너무 불분명하거나 포괄적으로 문서화되거나, 또는 전혀 문서화되지 않으면 의미하는 것에 대해 지속적으로 합의가 결여될 수 있어서 적절하게 관리하는 것이 불가능해 질 수 있다.

 

한편 기대와 그것을 관리하는 수단이 너무 경직되어 콘크리트 구조물과 같은 경우, 프로젝트를 실행하는 동안 정상적인 업무 변화 때문에 받아들여야 할 프로젝트 범위 변경 요청을 받아들이지 못하면 유연성이 불충분하게 될 것이다.

 

이것은 모범적인 균형 잡기 행위로 그러한 필요성을 없앨 수 있는 독단이나 방법은 없다. PMBOK에서 인용한 부분은 프로젝트 범위 관리가 속해 있는 절이다. 이것은 거의 기대 관리와 동일하다. 거의 그렇다. 어떤 의미에서, 차이점은 기대관리가 실제로 문서화된 범위는 물론이고 프로젝트 팀원과 프로젝트 책임자가 생각하는 범위 즉 인지한 범위를 포함한다는 점이다.

 

이것은 다소 독심술이나 점술처럼 들리 수도 있다. 그러나 기대를 이렇게 생각하는 것은 프로젝트를 진행하는 동안 우리를 삼킬 수 있는 크레바스처럼 입을 벌리고 있는 불투명한 부분과 빠진 부분을 이해하는데 도움을 준다. 우리는 모든 이해관계자들과 끊임없이 대화를 나누어야 한다는 필요성에 대해 일관되게 인식할 필요가 있다. 그래야 범위 정의가 명확해지고 그 결과 서로 이해하고 있는 기대를 확인할 수 잇다.

 

이제 자극적인 용어를 사용하여, 기대를 잘 관리하기 위하여 범위와 범위 변경에 의해 일어나는 영향에 대해 극단적으로 의사소통 할 필요가 있다.

 

기대는 너무 비공식적인 것인가?

“기대 관리”라는 용어는 대부분의 사람들에게 비공식적인 것으로 들린다. 어떤 관리자들은 구두로 기대를 결정하고 관리하는 것 쯤으로 생각한다. 어떤 의사결정자는 구두로 그리고 비공식적으로 업무를 수행하는 것을 좋아해, 프로젝트 관리자가 범위와 기대를 관리하기 어렵게 만든다.

 

여기 유용한 접근방법이 있다 : 구두로 기대를 결정하는 회의를 한 후 모르긴 몰라도 서명이 필요한 체계적인 문서를 했을 때, 우리가 찾을 수 있는 균형점을 발견할 수 있을 것이다. 대부분의 상황에서, 이것은 어느 정도 공식적인 것과 비공식적인 것을 결합한 것일 것이다.

 

이러한 접근방법은 고객이 실제로 턴키 관계를 원하는(때때는 잠재의식적으로) 업체/고객간의 상황에서도 사용할 수 있지만, 업체는 더 잘 알고 있다. 여하튼, 프로세스는 처음부터 다시 시작해야 한다.

 

다시 말해, 처음의 의미 있는 기대 결정 회의에서, 업체는 서명이 필요한 문서를 철저하게 확인해야 한다. 필자는 이 방법을 사용해 왔는데 항상 성공적이었다. 필자는 매우 비공식적인 스타일의 고객관리자와 함께 일 한 적이 있다. 그는 논의한 내용을 문서로 만들자 처음에는 놀라는 표정이었다. 그러나 그럴만한 가치가 있다고 생각하고 거기에 서명해다. 예비적인 논의이었기 때문에, 그 시점에서 그가 약속한 범위는 적었다. 그러나 이것으로 인해, 이야기하게 되고, 자유롭게 브레인스토밍을 하고, 구두로 논의하고 합의하게 되었다. 필자는 문서로 만들어(이 경우에는 공문서로) 서명을 해달라고 했다. 이 문서는 계약서의 범위 그리고 부분적으로 프로젝트의 범위를 문서화할 때 추적 문서 역할을 제공했다.

 

요구와 범위 정의

논의를 진행하는 동안 합의된 것이 무엇인지를 알아내기 위해 문서를 사용하는 것은 보다 공식적인 요구와 범위 문서화를 할 필요성을 없애주지는 못한다. 그러나 공문서나 회의록 등 요구문서를 훌륭하게 조직하고 이해하기 쉽게 작성하는 것을 도와줄 수 있다.

 

(그런데 회의록을 요청했을 때, 필자는 그 자체에 요령이 없다는 것을 발견했다. 회의록의 문제는 항상 혼란스럽다는 것이다. 사실 회의에서 일어난 것을 정확하게 반영한다면, 결코 혼란스럽지는 않을 것이다.)

 

회의가 끝난 후 문서를 만드는 목적은 회의에서 일어난 것을 기록하는 것이 아니다(그것은 회의록의 목적이다). 논의된 것과 합의된 것을 기록하는 것이 목적이다. 회의록이나 회의 메모는 회의의 내용을 포착하기 위해 도움을 주는 도구들이지만, 모든 의사결정자들이 합의할 수 있는 방법으로 무엇이 일어나고 무엇이 논의 되었는지를 요약하는 것이 핵심이다.

 

문서는 (필자의 경우를 예로 들면) 고객이 보고 수정을 할 수 있는 기회를 주기 위해 초안 형태로 제시되어야 한다. 그래서 마지막 문서는 그들이 기억하고 합의하는데 문제가 없다는 것을 보여주어야 한다. 자연적으로, 적시에 전달되는 것이 중요하다. 대개 회의가 끝난 후 48시간 안에 문소가 전달될 수 있게 해야 한다.

어떤 생각 : 답변 : 변경관리

프로젝트의 범위를 계획할 때 직면하는 문제는 근거가 우리들에 의해 불가피하게 바뀐다는 점이다. 예를 들어, 업무 요구가 문서화되자 마자, 변경이 일어난다. 이 주제에 관한 두 가지 생각을 들어보자 :

l  프로젝트 수명은 장애를 정의하지만 그것을 없애기 위해 변명을 늘어놓지 않는다는 사실.

l  변경을 계획하는 유일한 방법은 하향식으로 해야 한다. 변경의 수용을 위해서는 만일 시스템이 있다면 그것을 포함하여, 전체 프로젝트와 그것의 산출물을 설계하는 방법으로 구축되어야 한다.

 

프로젝트와 IT관리자들이 여러 해 동안 진행되는 개발 프로젝트에서 변경과 그 영향에 대해 불평을 늘어놓고 있다. 재미있는 것은, 운영하는 시스템에 대한 변경에는 관리하기 어려움에도 불구하고, 관리자들이 똑같이 불평하지 않는다는 점이다. 운영 시스템이 변경에 대해 보다 관리 가능하게 보이는 것은 사용자들이 매우 가까이에서 시스템을 보기 때문이며 시스템 주위에서 일하고 시스템을 돌리기 위해 그들이 필요하다고 생각하는 것을 변경하기 때문이다. 물론 이 경우에는 사용자로부터 불평이 나오지, 시스템 관리자로부터 나오는 것은 아니다.

 

중요 프로젝트에서 변경을 수용하려면, 프로젝트의 거의 모든 부분이 수용을 위한 수단을 내장하고 있어야 한다. 예를 들어, 프로젝트 수명주기의 모든 단계에서 변경을 관리하는 방법이 있어야 한다. 실행계획을 단계별로 변경을 예상하고 허용할 수 있는 방법으로 만들어야 한다. 시스템 설계는 주어진 제약 조건하에서, 가능한 한 유연해야 한다. 그래야 시스템을 운영하고 사용할 때 변경을 수용할 수 있다. 주어진 시간 안에 프로젝트에 심각한 영향을 주지 않고, 변경을 수용할 수 없을 경우에는, 논의가 필요하고, 해결책을 마련하고 명확하게 문서를 만들고 합의를 해 놓아야 한다.

 

서로 이야기 할까요!

한 번은 대규모 원격통신 회사에서 진행하고 있는 대형 프로젝트를 검토한 적 있다. 설계 단계가 끝나갈 때였으며 문제가 되는 현안이 있어 지연되고 있었다. 필자의 일은 사정을 개선하기 위해 할 수 있거나 해야 할 일을 찾아내는 것이었다.

 

필자는 전략계획수립팀에게 이야기 했고, 프로젝트 관리자에게 이야기 했다. 업무 부서장과 사용자 모임에서도 이야기 했다. 그런 다음 그들을 인사시켰다. 그때까지 그들은 만난 적이 없었다!

 

새로운 물류 시스템을 위한 훌륭한 전략계획이 수립되어 있었지만 사용자들이나 개발 팀과 전혀 논의한 적이 없었다. 프로젝트팀은 자신들의 진척 사항을 IT관리자에게는 보고하고 있었지만 자기 차례를 그저 기다리고 잇는 시험에 참여할 준비가 되어 잇는 사용자들에게는 전혀 보고하지 않았다. 서로 다른 기대와 계획 그리고 어젠더를 가지고 있는 업무팀은 실망스런 표정으로 서로 떨어진 세 개의 사무실에서 이야기를 나누고 있었다.

모든 이해관계자들의 마음을 하나로 묶는 것은 프로젝트 관리, 특히 계획수립단계에서 가장 어려운 측면 가운데 하나다. 프로젝트의 납기가 임박해지거나, 지연되고, 부정적인 영향의 위협을 받으면, 관련된 모든 그룹들이 모이는 경향이 있다. 그러나 이 시점에서 나온 조치나 결과는 부정적으로 될 가능성을 제공한다. 나중에는 덜 만족스러울지도 모르지만 아직 만일의 사태에 대하여 계획을 짤 수 있다는 희망이 보인다면 이해관계자는 함께 모여야 한다.

 

요약

기대의 결정과 관리에 대한 실패는 프로젝트 실패의 주요 원인임에 틀림없다. 그것은 프로젝트의 모든 측면을 통해 실행하는 매일 매일의 직무이기 때문에 그 자체가 쉬운 해결책을 빌릴 수 있는 그런 것은 아니다.

 

끊임없이 바뀌는 기대는, 시스템은 완벽하고 유연성 있게, 재고할 수 있도록 구축되어야 한다는 요구에 대해 독자들이 확정할 수 없다는 말을 몇몇 사람들이 하게끔 원가를 재촉한다. 다른 사람들은 새로운 시스템이 구축되거나 예상될 경우 그 동안에는 변경내용이나 시방서가 확고하게 동결되어야 한다고 이야기 한다.

 

우리가 진정으로 예축가능하고, 직업적인 결과를 만들어 내면서 동시에 필요한 변화를 수용할 수 있도록 유인하고 충분히 체계화된 계획을 유지하고, 문서와 기법을 설계할 필요가 있기 때문에 프로젝트 관리가 어렵다는 이유라는 것을 우리들 가운데 현실주의자들은 알고 있다. 업무는 위협적이지만, 이것은 계속해서 혈액을 공급받아야 하는 PM의 모습 가운데 하나이다. 그렇게 생각하지 않는가?

 

Frank Winter는 거의 40년 동안 기술개발자, 팀 리더, 프로젝트 관리자, 프로그램 관리자, 컨설턴트 그리고 IT서비스 산업 임원 들을 역임했으며 컨설팅과 정보 기술 분야의 풍부한 경험을 보유하고 있다. 그는 현재 프로젝트와 프로그램 관리와 관계된 토픽을 가지고 컨설팅, 저작 활동 그리고 강연을 하고 있으며, Gantthead.Com에 좋은 기사를 많이 제공하고 있다. 그의 전자우편 주소는 winter@att.net이다.

Gantthead.Com 판권 소유

출처 보기