완벽한 프로젝트를 위한 7가지 기본 원칙
완벽한 프로젝트를 위한 7가지 기본 원칙
이는 시나리오와 유사한 성격을 지닌다. 새로운 프로젝트 참여자는 열정적으로 작업에 몰두한다.
하지만 어떤 의미에서 보면 새로운 사업 소프트웨어를 도입하는 활동은 일정표 또는 예산의 문제를 남기며 어처구니 없게도 본류에서 벗어나는 감이 있다. 이런 사태를 피하려면 SMB는 성공적인 프로젝트 관리의 초석이라 할 기본 요소들, 즉 기술, 직원, 절차 등을 연계시키는 일에 주안점을 두어야 한다. 이것이야말로 상이한 과정 및 중요한 상황 하에서 프로젝트를 유지해 나갈 수 있는 방법이기도 하다.
인류의 역사는 프로젝트의 성공과 실패의 역사라 해도 과언이 아니다. 오늘날 경이로운 역사적 프로젝트 가운데 하나로 추앙 받는 것이 바로 이집트 기자에 건설된 피라미드다. 성서에 등장하는 바벨탑은 잘못된 프로젝트가 어떤 결과를 나타내는가를 여실히 보여준 프로젝트라고 할 수 있다. 오늘날 수많은 IT 프로젝트는 여러 가지 다양한 의견들이 불협화음을 보이는 와중에 부적절한 기술의 선택과 조화롭지 못한 절차 등이 어우러져 수행된다. 다음에 제시하는 7가지 기본 원칙은 SMB이 IT 프로젝트를 효율적으로 그리고 성공적으로 수행하는데 도움이 될 것이다.
1. 가능한 한 명확한 프로젝트의 목표 및 요구사항 규정
목표와 요구사항 등을 정확하게 정의하지 않았기 때문에 실패하게 되는 프로젝트가 의외로 많다. IT 프로젝트에서는 사업 관리라는 측면을 중시해야 한다. 프로젝트의 목표 및 요구사항을 명확하게 규정하여 전달해야 한다. 예를 들어 ‘1년 내에 IT 비용을 50%까지 절감하는 것이 목표다’라는 식으로 분명하게 기대 수준을 정해 놓아야 한다. 이렇듯이 프로젝트의 성공 여부는 그 시작부터 결정된다고 해도 과언이 아니다. 따라서 프로젝트를 실행하기 전에 우선 다음과 같은 사항을 분명히 짚고 넘어가야 한다. 즉, 프로젝트를 수행하는 사람이 누구인가? 프로젝트 담당 임원은 누구이고 관련 직원은 누구인가? 프로젝트 개시 시기는 언제이며 어제 완료되는가? 프로젝트를 통해 변화되는 부분이 무엇인가? 이러한 변화를 어떻게 관리할 것인가? 프로젝트 참여자와 프로젝트 고객(경연진, 이사진) 등을 포함한 핵심 구성원들은 사전에 이러한 문제를 분명히 확인해 두어야 한다.
2. 일정표 및 예산 계획
관련 연구 결과, 프로젝트 상의 일정표가 제대로 지켜지지 않고 예산 계획이 어그러지는 경우가 자주 발생한다는 점에 대개의 연구자들이 동의하는 편이다. 예기치 못한 요인으로 인해 또는 소프트웨어를 설치하고 가동하는데 생각보다 더 많은 시간이 걸려 일정표 상에 허용된 시간을 초과하는 일이 다반사다. 때문에 좀 더 여유 있게 시간 조정을 할 필요가 있다. 수 개월 정도 걸리는 장기 프로젝트인 경우 이는 더욱 중요한 문제가 된다. 일정표를 작성할 때는 낙관적인 시각을 지양하고 좀 더 신중하게 목표를 정하는 것이 필요하다. 새로운 프로젝트에 나중에 합류하는 사람이 있다면 훈련 기간을 충분히 주어야 한다. 그 시스템을 수용하느냐의 여부는 시스템의 성공과 실패를 좌우하는 결정적 요소가 되기 때문이다. 또한 프로젝트 비용에 관해서는 지속적으로 조사, 감독해야 한다. 절차의 투명성을 높이는 것은 물론 프로젝트가 끝났을 때 불미스런 일이 발생하지 않게 하려면 비용에 관한 감시 절차가 필요하다.
3. 적합한 팀원 구성
이 문제는 매우 미묘하고도 신중하게 다루어야 할 부분이다. 대부분의 경우 ‘전체는 부분들의 합과는 본질적으로 다르기’ 때문이다. 축구나 핸드볼과 같은 스포츠에서처럼 팀원을 제대로 구성했느냐의 여부가 성공과 실패를 가르는 결정적 요소가 된다. 각 구성원에게 적당한 임무를 할당해야 하며 임원과 직원을 혼합하여 팀을 구성해야 한다. 임원들만으로 구성된 팀은 실패할 가능성이 높다. 또한 직원만으로 구성된 팀도 역시 결과는 마찬가지다. 개별적으로는 모두 유능하고 적합한 사람이라 해도 관리 경험이 없는 직원들이기 때문에 팀이 원활하게 돌아가는데 문제가 있을 수 있다. 그리고 프로젝트 상의 역할과 책임 차원에서 팀원 간의 상호 관계가 이루어져야 하다.
또한 지나친 위계질서는 피하는 것이 좋다. 경직된 위계질서는 공개적이고 개방적인 토론을 저해하고 팀원 간의 갈등을 심화시킬 우려가 있다. 프로젝트에 참여하는 임원과 직원은 프로젝트가 진행되는 과정에서도 지속적인 훈련을 받아야 한다.
4. 위험 분석
위험 분석의 목적은 의사 결정 시점에서 좀 더 투명성을 확보하고 또 발생 가능한 ‘최악의 시나리오’를 사전에 분석하여 적절한 대응책을 마련하려는 데 있다. ‘위험이 없으면 이익도 없다’라는 슬로건 하에 진행되는 프로젝트는 십중팔구 실패하기가 쉽다. 하지만 여러 가지 상황을 다각도로 검토하여 제대로 계획된 프로젝트라 해도 위험 요소는 항상 내재되어 있기 마련이다. 일반적인 프로젝트 위험에는 프로젝트 기간 중 질병으로 인한 중요 구성원의 이탈, 마감 시한에 맞추지 못함, 책임 소재의 갈등, 팀원 간의 마찰 등이 포함된다. 프로젝트 자체에서 발생하는 프로젝트 위험과 소프트웨어 결함과 같은 제품 위험을 명확히 구분할 필요가 있다. DIN 69905에 따르면 위험 분석은 ‘프로젝트 분석의 일부로서 프로젝트 위험을 다루는 것’이라고 한다. 하지만 이론적으로 프로젝트를 시작하기 전에 가능한 한 신속하게 위험 분석을 해야 한다는 점을 생각하면 이러한 협의의 정의는 적당하지 않다고 볼 수 있다. 사전 분석이 기능해야만 프로젝트를 위험에 빠뜨리게 할 요인들을 평가하여 대응책을 마련할 수 있다. 장기적인 프로젝트일 경우에는 사전 위험 분석이 더욱 중요한 역할을 한다. 관리상의 전략적 결정 결과에 따라 프로젝트의 목표가 변하기 때문이다. 프로젝트 팀은 이러한 결정 과정에 아무런 영향력을 행사하지 않는다. 이런 결정 과장은 예기치 못한 상황 요인으로 작용하기 때문에 위험 분석을 통해 미리 그 결과를 예측하고 평가하는 것이 중요하다.
5. 각 단계별 프로젝트 관리 및 감시
“시간, 예산, 복잡성 등이 특정 수준을 넘어섰다고 판단되면 속히 적절한 방법을 이용하여 이를 관리하고 감시해야 한다. 또한 이러한 관리는 팀, 기업 문화, 프로젝트 등에 적합한 방식으로 이루어져야 한다.” 니콜라우스 울프 박사의 말이다. IT 프로젝트는 원래 추산했던 것보다 시간도 더 오래 걸리고 비용도 더 많이 드는 것으로 알려져 있다. 효과적인 프로젝트 관리를 통해 비교적 원만한 수행을 도모하고 또 만족스런 프로젝트 결과도 얻을 수 있다. 프로젝트 계획을 현실과 비교하는 방법을 통해 목표와 실제 데이터를 지속적으로 비교하는 작업은 프로젝트 관리의 중요한 측면이다. 이를 통해 목표와 실제 간에 괴리가 생기는 경우 프로젝트의 신제 절차를 원래 계획했던 것에 맞춰 갈 수 있다. 현재 상황이 프로젝트 상의 다음 단계에 어떤 영향을 주는지를 판단하는 것도 중요하다. 프로젝트의 모든 참여자 간의 광범위한 의사소통뿐 아니라 목표에 비추어 달성된 업무의 정도 그리고 일정표 상의 진척 상황 등을 바탕으로 지속적으로 프로젝트 계획을 개선해나가는 것도 무엇보다 중요하다. 기간이나 자원, 개별적 목표 등에 비추어 계획을 재조정해야 한다. 프로젝트가 진행되는 동안에 기간 또는 목표 상의 변화가 생기는 경우 서면으로 기록하여 문서화 하는 것이 좋다. ‘구두’작업은 무엇을 해야 하고 또 무엇을 하지 말아야 하는지에 대해 정확하게 알지 못하게 하기 때문에 혼란을 야기할 수 있다. 도구의 문제는 차치하고 능동적이고 효과적인 프로젝트 관리가 이루어지려면 무엇보다 명확한 정보, 의사소통, 협력, 관리, 팀 문화 등이 요구된다. 이러한 것이 결여되면 프로젝트가 성공할 가능성이 희박해진다.
6. 회의록 작성
회의록은 개별적 모임에서 결정된 사항을 문서로 남긴 것 이상의 의미를 갖는다. 회의록은 프로젝트의 과정 및 일반적인 맥락을 이해하는 정보의 요체다. 보통은 프로젝트 모임을 가진 후에 작성한다. 항상 작성해야 한다는 사실을 잊으면 안 된다. 특정 양식에 맞춰 작성한 후 배부 명단을 보고 송부한다. 그런데 지금까지는 잘 활용이 안 되었다. 대부분이 받아 놓기만 하고 읽지 않았기 때문이다. 회의 또는 모임은 프로젝트 작업에서 중요한 위치를 차지한다. 그렇기 때문에 회의록을 작성하는 것도 그만큼 중요한 일이다. 회의록을 작성할 때는 애매모호한 내용이 없도록 객관적으로 보고하는 형식이어야 한다. 회의 결과, 대화 내용, 기타 사항 등을 기록으로 남겨둔다. 이렇게 하면 회의 과정에 무슨 일이 발생했는지 기억하는데 도움이 된다. 회의에 참석한 사람의 기억을 상기시키는데도 도움이 될 뿐만 아니라 ‘그런 결정을 내린 적이 없는데’ 따위의 불필요한 논쟁을 피하는데도 결정적으로 도움이 된다. 회의에 참석했는지 여부와 상관없이 모든 팀 구성원에게 그리고 프로젝트를 지시한 관련 인원에게도 회의내용을 작성하여 송부한다.
7. 마무리
대개의 경우 일반적인 평가 및 보고를 끝으로 프로젝트가 마감된다. 프로젝트는 끝나고 새로운 소프트웨어에 대한 실제 경험을 처음으로 사용할 수 있게 된다. 그렇다면 이제 프로젝트에 대해 전반적으로 검토해보아야 할 시점이다. 무엇이 잘못되었는지 그리고 무엇을 달성하였는지, 기대했던 것보다 더 좋은 성과는 무엇이고 더 나빠진 것은 무엇인지 등을 평가해야 한다. 그렇다고 프로젝트에 참여했던 임원이나 직원들이 자화자찬하는 자리가 되어서는 안 되고 전체 프로젝트 과정을 면밀히 평가하는 시간이 되어야 한다. 주로 긍정적인 평가를 내리는 자리가 될 수도 있겠지만 말이다. 더 나아가 다음과 같은 질문을 해본다.
– 다음 프로젝트에 참고할만한 것을 배웠다면 그것은 무엇인가?
– 똑같은 실수를 반복하지 않기 위해서는 어떤 조치를 취해야 하는가?
이러한 질문에 대해 진지하게 생각해본다면 앞으로의 IT 활동에 있어 더할 나위 없이 유용한 정보를 얻게 될 것이다. 프로젝트에 대한 결론을 내리는 시점에서는 프로젝트에 참여했던 모든 사람에 대해 수고와 노력을 치하할 필요가 있다. 앞으로의 프로젝트에 있어 그 성공을 좌우하는 가정 중요한 요소는 뭐니뭐니해도 ‘인적 요소’이기 때문이다.
