제1회 프로젝트는 실패하는 것이 당연하다.
1. IT 프로젝트의 대부분은 실패로 끝난다.
IT 프로젝트가 실패하는 이유에는 성공할 것이라고 전제한 매니지먼트를 하기 때문이다. IT 프로젝트의 성공율은 생각 외로 낮으며 이러한 상황을 개선하기 위해서는 "실패를 전제로 한 매니지먼트"에 유의해야 한다. 실패를 전제로 한 매니지먼트란 위기 관리에 중점을 둔 매니지먼트라는 것이 된다.
IT 프로젝트의 대부분은 실패로 끝난다.
성공율 16%. 이것은 어떤 개발툴 벤더가 조사한 미국에서의 IT 프로젝트의 성공율이다. 그 조사에 의하면 2005년 미국에서 수행된 프로젝트는 약 17만 건이며, 그 중에서 기능, 예산, 납기 등이 당초의 상정 내에 들어간 것은 16%였다고 한다.
이러한 조사 결과의 정도에 대해서는 검토의 여지가 있긴 하지만 아마추어라도 읽어낼 수 있는 분명한 경향은 "IT 프로젝트는 실패할 확률이 높다"라는 것이다.
프로젝트 매니지먼트나 소프트웨어의 품질 관리가 중요시되는 요즘에 이 숫자는 이상하다고 할 수도 있을 것이다(그러므로 중요성이 주장되는지도 모른다).
그러면 프로젝트는 왜 실패하는 것일까. 그 원인은 여러가지를 생각할 수 있지만 원래 "IT프로젝트는 실패할 확률이 높다" 라는 것을 전제로 한 매니지먼트를 하지 않는다는 것에 근본적인 원인이 있다고 필자는 생각한다. 평범하게 표현한다면 IT 프로젝트를 남들처럼 추진한 것은 대체적으로 실패하는 것이다. 그러면 어떻게 대응하면 IT 프로젝트를 성공으로 이끌 수 있는 것일까.
본 연재에서는 "IT 프로젝트는 실패한다"는 것을 전제로 한 프로젝트 매니지먼트의 구체적인 예를 소개하고자 한다. 대상 독자로서 유저기업(발주측)의 프로젝트 매니저 혹은 관리직인 분을 상정하기로 한다. 왜냐하면 IT 프로젝트를 매니지먼트해야 할 의무는 본질적으로는 발주자측이기 때문이다. 한편 본 연재에서는 발주측에게서는 보이지 않는 개발회사(수주측)의 심리상황 등도 섞어가면서 프로젝트가 실패하는 본질적인 과제에 대해 보다 깊이 들어가 보고자 한다.
2. 실패를 전제로 한 매니지먼트란 무엇인가?
반복된 내용이 되는데 IT 프로젝트를 성공시키는 포인트는 "실패를 전제로 한 매니지먼트" 를 실시한다는 것이 필자의 주장이며, 이 생각은 본 연재의 핵심이라고도 할 수 있다.
그러면 "실패를 전제로 한다"는 것은 구체적으로 무슨 말일까. 즉, 성공을 전제로 했을 경우와 실패를 전제로 했을 경우의 매니지먼트 방법에서 어떠한 차이가 생기는 것일까.
예를 들고 생각해 보기로 한다. 그러기 위해서는 성공이 전제가 되는 행위와 실패가 전제가 되는 행위를 상정할 필요가 있는데 여기에서는 "차를 운전해서 가까운 우체통에 편지를 넣으러 간다"는 행위를 "성공을 전제"로 한 행위라고 하고 "로켓을 쏘아올려 인공위성을 궤도에 올려 놓는다"라는 행위를 "실패를 전제로 한 행위"의 예로서 들기로 한다. 조금 과장되지만 이해해 주었으면 한다.
그런데 당신이 "차를 운전해서 가까운 우체동에 편지를 넣으러 간다" 라는 행위와 "로켓을 쏘아 올려 인공위성을 궤도에 올려 놓는다" 라는 행위의 프로젝트 매니저가 되었을 때 매니지먼트 방법에는 어떠한 차이가 날까.
"로켓을 쏘아 올렸던 적이 없기 때문에 모르겠습니다" 라는 말을 듣게되면 그걸로 끝이지만 차에 비해 로켓의 경우가 여러가지로 체크할 것이 많아지는 것만은 틀림없다. 실제로 차로 나가기 전에 일일이 연료펌프가 정상적으로 동작하는지를 체크하거나 하지는 않지만 로켓 발사에서는 모든 항목에 대해서 체크하는 것은 당연하며, 센서가 이상을 보이게 되면 발사는 당연히 즉각 중지가 된다.
로켓을 쏘아 올릴 때 엔지니어들은 모든 것을 의심하게 된다. 왜냐하면 발사가 성공되지 못하는 경우가 많다는 것을 인식하고 있기 때문이다.
즉, "실패를 전제로 한다"는 것은 바꾸어 말하면 "뭐든지 의심한다"라는 것일 뿐이다. 성선설을 버리고 성악설에 서서 매니지먼트를 실시한다는 말로 바꿀 수도 있을 것이다. 당연한 이야기라고 하면 당연한 이야기겠지만 이 차이가 크다는 것이다.
물론 단지 의심하기만 하면 좋은가 하면 그렇지도 않다. 매니지먼트에도 당연히 "질"이 요구되는데, 실패를 전제로 한 매니지먼트에서의 질이란 단순히 의심하기만 하는 것이 아니라 의심한 부분에 누락이 없는지 혹은 의심한 포인트를 확실히 알고있는지도 중요하다. 특히 실제 프로젝트에서는 시간도 자원도 한정되어 있다. 거기에서 얼마나 정확하게 필요한 것을 의심하는지도 매우 중요한 요소가 된다.
여러가지를 이야기했는데 "실패를 전제로 한" 매니지먼트란 "의심을 하는 것"이며, 결국 위기관리에 중점을 둔 프로젝트 매니지먼트에 수렴되게 된다. 이렇게 이야기하면 "뭐야, 이미 그렇게 하고있어"라고 말할지도 모른다. 하지만 중요한 것은 어떠한 위기관리를 실시하고 있는가이다.
3. 처음부터 리스크 팩터를 파악 하였는가?
처음부터 리스크 팩터를 파악하였는가
"실패를 전제로 한 매니지먼트(위기관리)의 첫걸음은 리스크 팩터의 파악임은 말할 필요도 없다. 그렇다면 당신은 시스템 구축 시의 리스크 팩터를 어느정도 파악하고 있을까. 실제로 열거해 보고자 한다. 물론 거의 생각이 떠오르지 않더라도 걱정할 필요는 없다. 본 연재는 IT 프로젝트에서의 리스크 팩터 열거와 대응책의 소개를 최종 목표로 한다.
물론 본 연재에서는 시스템 다운이나 시큐리티 대책 운운하면서 여러가지 이야기를 할 생각은 전혀 없다. 연재를 하면서 자세히 소개하겠지만 IT 프로젝트의 성공 여부에 시스템 아키텍쳐는 거의 영향을 주지 않는다. 여러분이 좋아하는 Windows나 linux 인가 하는 논의는 프로젝트의 가부에는 유감스럽게도 전혀 관계가 없다. 프로젝트의 성공 여부에 영향을 주는 것은 기본적으로 모두 "사람"에게서 기인하는 것이며 사람을 중심으로 위기관리를 만들어내야 한다.
원래 실패란 무엇인가를 파악하는 것인가
마지막으로 "실패란 무엇인가"에 대해서도 언급해 두고 싶다. 지금까지 "실패를 전제로 한 매니지먼트"의 중요성에 대해 게속 이야기 했었는데, 원래 실패란 무엇인가에 대해서 생각해 본 적이 있는가. 실패란 굳이 이야기하면 어떤 기준에 대조하여 허용하기 어렵다고 판단되는 사상이라고 표현할 수 있다. 하지만 여기서 중요한 것은 실패인지 어떤지를 판단하는 기준은 상황에 따라서는 변한다는 것을 인식하고 있는 것이다. 즉 어떤 기준에 대해서는 실패이지만 다른 기준에 대해서는 성공이라고 할 수도 있다.
예를들면 IT 프로젝트에 대해서는 비지니스 상의 사정으로 인해 도중에 납기가 단축되는 경우도 적지 않다. 어떻게 해도 납기에 타협이 이루어지지 않아 프로젝트가 장애에 부딪혀 버리는 경우도 있다. 이러한 경우 당초의 납기라면 충분히 성공할 수 있었음에도 불구하고 납기가 변경된 탓에 실패라는 결과를 이루어내지 못하는 경우도 있다. 또 기능, 납기, 예산, 품질의 모든 기준을 만족시켰음에도 불구하고 그 시스템이 제공하는 서비스 자체가 비지니스적으로 적자여서 결과적으로 프로젝트가 샐패했다고 판단되어 버리는 경우도 있다.
IT 프로젝트를 성공적으로 이끌기 위해서는 실패란 무엇인지 이해한 후에 발주자가 시스템의 목적이나 평가 기준을 명확하게 하여 함부로 변경하지 않는 마음가짐도 필요한 것이다.
IT 프로젝트가 실패하는 이유는 성공하는 것을 전제로 한 매니지먼트를 하고 잇기 때문에 있다. IT 프로젝트의 성공율은 생각 외로 낮고 이러한 상황을 개선하기 위해서는 "실패를 전제로 한 매니지먼트"를 유의해야 한다. 실패를 전제로 한 매니지먼트란 위기 관리에 중점을 둔 매니지먼트가 된다.
1. IT 프로젝트의 대부분은 실패로 끝난다.
IT 프로젝트가 실패하는 이유에는 성공할 것이라고 전제한 매니지먼트를 하기 때문이다. IT 프로젝트의 성공율은 생각 외로 낮으며 이러한 상황을 개선하기 위해서는 "실패를 전제로 한 매니지먼트"에 유의해야 한다. 실패를 전제로 한 매니지먼트란 위기 관리에 중점을 둔 매니지먼트라는 것이 된다.
IT 프로젝트의 대부분은 실패로 끝난다.
성공율 16%. 이것은 어떤 개발툴 벤더가 조사한 미국에서의 IT 프로젝트의 성공율이다. 그 조사에 의하면 2005년 미국에서 수행된 프로젝트는 약 17만 건이며, 그 중에서 기능, 예산, 납기 등이 당초의 상정 내에 들어간 것은 16%였다고 한다.
이러한 조사 결과의 정도에 대해서는 검토의 여지가 있긴 하지만 아마추어라도 읽어낼 수 있는 분명한 경향은 "IT 프로젝트는 실패할 확률이 높다"라는 것이다.
프로젝트 매니지먼트나 소프트웨어의 품질 관리가 중요시되는 요즘에 이 숫자는 이상하다고 할 수도 있을 것이다(그러므로 중요성이 주장되는지도 모른다).
그러면 프로젝트는 왜 실패하는 것일까. 그 원인은 여러가지를 생각할 수 있지만 원래 "IT프로젝트는 실패할 확률이 높다" 라는 것을 전제로 한 매니지먼트를 하지 않는다는 것에 근본적인 원인이 있다고 필자는 생각한다. 평범하게 표현한다면 IT 프로젝트를 남들처럼 추진한 것은 대체적으로 실패하는 것이다. 그러면 어떻게 대응하면 IT 프로젝트를 성공으로 이끌 수 있는 것일까.
본 연재에서는 "IT 프로젝트는 실패한다"는 것을 전제로 한 프로젝트 매니지먼트의 구체적인 예를 소개하고자 한다. 대상 독자로서 유저기업(발주측)의 프로젝트 매니저 혹은 관리직인 분을 상정하기로 한다. 왜냐하면 IT 프로젝트를 매니지먼트해야 할 의무는 본질적으로는 발주자측이기 때문이다. 한편 본 연재에서는 발주측에게서는 보이지 않는 개발회사(수주측)의 심리상황 등도 섞어가면서 프로젝트가 실패하는 본질적인 과제에 대해 보다 깊이 들어가 보고자 한다.
2. 실패를 전제로 한 매니지먼트란 무엇인가?
반복된 내용이 되는데 IT 프로젝트를 성공시키는 포인트는 "실패를 전제로 한 매니지먼트" 를 실시한다는 것이 필자의 주장이며, 이 생각은 본 연재의 핵심이라고도 할 수 있다.
그러면 "실패를 전제로 한다"는 것은 구체적으로 무슨 말일까. 즉, 성공을 전제로 했을 경우와 실패를 전제로 했을 경우의 매니지먼트 방법에서 어떠한 차이가 생기는 것일까.
예를 들고 생각해 보기로 한다. 그러기 위해서는 성공이 전제가 되는 행위와 실패가 전제가 되는 행위를 상정할 필요가 있는데 여기에서는 "차를 운전해서 가까운 우체통에 편지를 넣으러 간다"는 행위를 "성공을 전제"로 한 행위라고 하고 "로켓을 쏘아올려 인공위성을 궤도에 올려 놓는다"라는 행위를 "실패를 전제로 한 행위"의 예로서 들기로 한다. 조금 과장되지만 이해해 주었으면 한다.
그런데 당신이 "차를 운전해서 가까운 우체동에 편지를 넣으러 간다" 라는 행위와 "로켓을 쏘아 올려 인공위성을 궤도에 올려 놓는다" 라는 행위의 프로젝트 매니저가 되었을 때 매니지먼트 방법에는 어떠한 차이가 날까.
"로켓을 쏘아 올렸던 적이 없기 때문에 모르겠습니다" 라는 말을 듣게되면 그걸로 끝이지만 차에 비해 로켓의 경우가 여러가지로 체크할 것이 많아지는 것만은 틀림없다. 실제로 차로 나가기 전에 일일이 연료펌프가 정상적으로 동작하는지를 체크하거나 하지는 않지만 로켓 발사에서는 모든 항목에 대해서 체크하는 것은 당연하며, 센서가 이상을 보이게 되면 발사는 당연히 즉각 중지가 된다.
로켓을 쏘아 올릴 때 엔지니어들은 모든 것을 의심하게 된다. 왜냐하면 발사가 성공되지 못하는 경우가 많다는 것을 인식하고 있기 때문이다.
즉, "실패를 전제로 한다"는 것은 바꾸어 말하면 "뭐든지 의심한다"라는 것일 뿐이다. 성선설을 버리고 성악설에 서서 매니지먼트를 실시한다는 말로 바꿀 수도 있을 것이다. 당연한 이야기라고 하면 당연한 이야기겠지만 이 차이가 크다는 것이다.
물론 단지 의심하기만 하면 좋은가 하면 그렇지도 않다. 매니지먼트에도 당연히 "질"이 요구되는데, 실패를 전제로 한 매니지먼트에서의 질이란 단순히 의심하기만 하는 것이 아니라 의심한 부분에 누락이 없는지 혹은 의심한 포인트를 확실히 알고있는지도 중요하다. 특히 실제 프로젝트에서는 시간도 자원도 한정되어 있다. 거기에서 얼마나 정확하게 필요한 것을 의심하는지도 매우 중요한 요소가 된다.
여러가지를 이야기했는데 "실패를 전제로 한" 매니지먼트란 "의심을 하는 것"이며, 결국 위기관리에 중점을 둔 프로젝트 매니지먼트에 수렴되게 된다. 이렇게 이야기하면 "뭐야, 이미 그렇게 하고있어"라고 말할지도 모른다. 하지만 중요한 것은 어떠한 위기관리를 실시하고 있는가이다.
3. 처음부터 리스크 팩터를 파악 하였는가?
처음부터 리스크 팩터를 파악하였는가
"실패를 전제로 한 매니지먼트(위기관리)의 첫걸음은 리스크 팩터의 파악임은 말할 필요도 없다. 그렇다면 당신은 시스템 구축 시의 리스크 팩터를 어느정도 파악하고 있을까. 실제로 열거해 보고자 한다. 물론 거의 생각이 떠오르지 않더라도 걱정할 필요는 없다. 본 연재는 IT 프로젝트에서의 리스크 팩터 열거와 대응책의 소개를 최종 목표로 한다.
물론 본 연재에서는 시스템 다운이나 시큐리티 대책 운운하면서 여러가지 이야기를 할 생각은 전혀 없다. 연재를 하면서 자세히 소개하겠지만 IT 프로젝트의 성공 여부에 시스템 아키텍쳐는 거의 영향을 주지 않는다. 여러분이 좋아하는 Windows나 linux 인가 하는 논의는 프로젝트의 가부에는 유감스럽게도 전혀 관계가 없다. 프로젝트의 성공 여부에 영향을 주는 것은 기본적으로 모두 "사람"에게서 기인하는 것이며 사람을 중심으로 위기관리를 만들어내야 한다.
원래 실패란 무엇인가를 파악하는 것인가
마지막으로 "실패란 무엇인가"에 대해서도 언급해 두고 싶다. 지금까지 "실패를 전제로 한 매니지먼트"의 중요성에 대해 게속 이야기 했었는데, 원래 실패란 무엇인가에 대해서 생각해 본 적이 있는가. 실패란 굳이 이야기하면 어떤 기준에 대조하여 허용하기 어렵다고 판단되는 사상이라고 표현할 수 있다. 하지만 여기서 중요한 것은 실패인지 어떤지를 판단하는 기준은 상황에 따라서는 변한다는 것을 인식하고 있는 것이다. 즉 어떤 기준에 대해서는 실패이지만 다른 기준에 대해서는 성공이라고 할 수도 있다.
예를들면 IT 프로젝트에 대해서는 비지니스 상의 사정으로 인해 도중에 납기가 단축되는 경우도 적지 않다. 어떻게 해도 납기에 타협이 이루어지지 않아 프로젝트가 장애에 부딪혀 버리는 경우도 있다. 이러한 경우 당초의 납기라면 충분히 성공할 수 있었음에도 불구하고 납기가 변경된 탓에 실패라는 결과를 이루어내지 못하는 경우도 있다. 또 기능, 납기, 예산, 품질의 모든 기준을 만족시켰음에도 불구하고 그 시스템이 제공하는 서비스 자체가 비지니스적으로 적자여서 결과적으로 프로젝트가 샐패했다고 판단되어 버리는 경우도 있다.
IT 프로젝트를 성공적으로 이끌기 위해서는 실패란 무엇인지 이해한 후에 발주자가 시스템의 목적이나 평가 기준을 명확하게 하여 함부로 변경하지 않는 마음가짐도 필요한 것이다.
IT 프로젝트가 실패하는 이유는 성공하는 것을 전제로 한 매니지먼트를 하고 잇기 때문에 있다. IT 프로젝트의 성공율은 생각 외로 낮고 이러한 상황을 개선하기 위해서는 "실패를 전제로 한 매니지먼트"를 유의해야 한다. 실패를 전제로 한 매니지먼트란 위기 관리에 중점을 둔 매니지먼트가 된다.
댓글을 달아 주세요