저도 처음에는 프로그래밍 언어만 할 줄 알면 프로그램을 만들 수 있다고 생각했던 적이 있었습니다.
실제로 그렇게 만들었던 프로그램도 꽤 많지요. ^^
하지만, 지금 생각해 보면 그렇게 만들었던 프로그램은 세상에 빛을 보지 못했거나 그리 오래 가지 못했던 것 같습니다.
반면에 체계적인 분석과 설계로 만들었던 몇몇 솔루션은 아직도 현업에서 잘 사용하고 있는 것을 볼 수 있었습니다.
바로 체계적인 분석과 설계라고 하는 것이 소프트웨어 개발 생명주기(Software Development Life Cycle)의 핵심이 아닌가 합니다.
여기에 추후 운영에 필요한 유지보수도 무시할 수는 없겠죠..
흔히 SDLC라고 하면 Waterfall, Prototyping, Spiral, RAD, Incremental Development, Evolutionary Development, 4 Generation 등의 모델을 들면서 어렵게 이야기 하는 경우가 많습니다.
물론 어떤 모형을 사용하는지 중요하지만, SDLC가 왜 필요한지 생각하지 않고 사용하는 것은 무의미하다고 봅니다.
단순하게 이런 모델로 개발을 진행한다고 하면서 코팅부터 하고, 프로젝트 개발이후 문서작업을 따로 하는 경우를 종종 봐왔기 때문입니다.
특정 모델들을 떠나서 가장 기본적인 또는 고전적인 SDLC의 형태는 다음과 같습니다.
프로젝트를 수행하려면 먼저 계획을 세워야 합니다. 투입될 인력이나 기간을 토대로 비용도 산정해 봐야하고 비즈니스 타당성도 검토해 봐야겠죠.. 물론 분석이나 설계 없이 이 작업을 정확하게 할 수는 없을 겁니다.
그러나 기존의 경험을 토대로 개괄적인 계획은 세워야만 프로젝트를 시작할 수 있을 겁니다.
추후 분석과 설계를 토대로 계획을 수정할 수도 있을 겁니다.
다음으로 분석과 설계입니다. 먼저 둘의 차이점에 대해서 알아보죠..
분석은 무엇(what)에 관심을 갖는 것이고 설계는 어떻게(how)에 관심을 갖는 겁니다.
만들어야 할 프로그램은 하나지만, 그것을 만드는 방법은 여러가지가 있을 수 있습니다.
즉, 분석은 만들려고 하는 프로그램을 하나로 명확하게 정의하는 과정이라고 할 수 있습니다.
설계는 프로그램을 만드는 방법을 찾아보는 것이라 할 수 있겠죠..
이것을 반대로 수행한다면 어떨까요? 어떻게 만들까를 먼저 생각하고 무엇을 만들지를 결정한다..
말이 안되는 것처럼 보이지만 의외로 현업에서 자주 발생하는 듯 합니다.
특히, 개발자의 관점에서 브레인스토밍 회의시 무엇을 만들지를 이야기 하고 있는데, 어떻게 구현할지를 걱정해서 "이건 안된다, 저건 안된다" 하는 경우를 종종 볼 수 있었습니다.
앞에서도 이야기 했듯이 분석에서 만들려고 하는 프로그램을 명확하게 정의해야 합니다.
그것을 어떻게 구현할 지는 설계 단계에서 결정하면 되는 것이죠..
"개발하지 못할 것이 어디 있겠는가?"하는 마인드가 분석 단계에서 중요하다고 볼 수 있겠죠..
설계 단계에서는 가장 효율적이고, 사용자가 편리하고, 개발을 빠르게 할 수 있는 방법을 찾아서 정리하고 모듈별로 나누는 작업까지 해야 겠죠..
코딩및 구현은 프로그램 개발에 있어 기본적인 사항이라 할 수 있습니다.
테스트의 중요성이 요즘 커져서 Test Driven Development라고 하는 방법도 나오고 있고, JUnit과 같은 단위 테스트 도구도 많이 발달한 상태입니다.
통합 테스트에 대해서는 좀 더 고려가 필요하겠죠...
마지막으로 유지보수입니다. 실제 보면, 개발 기간보다 시스템을 운영하는 기간이 더 길기 때문에 유지보수의 중요성이 점차 커지고 있습니다. 천만원에 개발했는데, 유지보수에 억단위가 들어간다면 좋은 시스템은 아니겠지요..
기본적인 SDLC의 단계를 나열해보니, 그리 어렵지 않다는 생각이 들겁니다.
물론 실제 적용하다 보면, 구현 단계에서 특정 부분을 변경할 경우 해당하는 분석/설계 산출물까지 변경해야 하는 번거로움이 존재할 수 있습니다.
이런 문제들은 반복이나 자동화 툴을 이용하는 다양한 SDLC의 모델들을 통해서 해결해 나갈 수 있을 것입니다.
중요한 것은 소프트웨어 개발 생명주기가 단순히 문서 작업을 늘리고, 이론적일 뿐인 방법론이 아니라 제대로 된 소프트웨어를 개발하기 위한 필수 사항이라는 것을 이해해야 한다고 봅니다.
2004년 5월 ~ 12월까지 월간 시사 컴퓨터에 연재된 천정락 교수님의 프로젝트 성공 요인 분석이란 자료가 있습니다. 4년여의 시간이 지났지만, 아직도 현재 진행하고 있는 IT 프로젝트에도 도움이 되는 이야기 인 듯 하여 정리해서 옮겨 봅니다.
1. 업무 변경 관리로 프로젝트 성공률을 높이자.
첫번째로 이야기 한 것은 변경 관리입니다. 프로젝트의 범위나 현업의 업무가 변경된 경우, 의사결정자들과 프로젝트 수행자들이 모여 업무 변경 관리 위원회를 만들고 체크해 나가야 한다는 이야기 입니다.
방법으로는 업무가 변경될 때마다, 단계별로, 프로젝트 막바지에 변경하는 방식이 있는데요 변경될 때마다 하는 것은 번거롭고 프로젝트 진행을 더디게 할 수 있구요. 단계별로 수행하는 것은 프로젝트가 잠시 멈추게 되므로 미리 일정을 반영해서 변경관리를 해야 한다고 합니다. 마지막에 일시에 수행하는 것은 프로젝트가 긴 경우, 업무 변경의 양도 많고 시간도 오래 걸리므로 주의해야 한다고 하네요..
어쨌든 추가 비용이 들더라도 업무 변경 관리는 어떤 형식으로든지 해야 합니다. 보통 프로젝트 수행시에 보면, 마지막에 설계 문서를 한꺼번에 다시 고치는 경우가 가장 많은 것 같습니다. 즉, 프로젝트가 끝난 후에 개발 결과물에 맞추어서 설계문서를 다시 만드는 것인데요.. 실질적인 변경관리라고 볼 수는 없다고 봅니다.
정말 성공하는 프로젝트를 만들고 싶다면, 설계를 변경하는 것에 대한 위험성을 고객이나 프로젝트 수행자 모두 인식하고 초기 설계부터 신중을 기해야 할 것입니다.
업무변경관리 전체보기...
기업은 오늘도 경쟁력 및 생산성 향상을 위해 크고 작은 여러 프로젝트를 진행하고 있다. 이 프로젝트 가운데 성공하는 프로젝트도 있고 실패하는 프로젝트도 있게 마련이다. 성공하는 프로젝트에는 성공하는 요인들이 있고 실패하는 프로젝트에는 그럴만한 요인이 있다. 요인 그 자체보다는 요인들을 어떻게 관리하느냐에 따라 프로젝트의 성패가 갈리는 경우도 많다. 이런 요인 가운데 "업무 변경을 어떻게 관리하느냐"는 성패에 상당한 영향을 미친다.
일반적으로 프로젝트의 최초 설계 시 프로젝트에서 성취해야 할 업무 범위를 설정한다. 이 범위를 바꾸는 것을 범위변경이라고 정의한다. 범위가 정해지고 나면 구체적인 업무를 정의한다. 이 정의된 업무가 여러 가지 내/외부 환경의 변화로 인해 변경되면 업무를 바꿔야 한다. 예를 들면 신상품 프로젝트일 경우 경쟁사에서 프로젝트 진행 중에 유사한 신제품을 먼저 출시했을 경우 여러 영향을 고려해 프로젝트를 취소할지 최초에 설계한 개념을 변경할지 신중히 결정해야 한다.
IT 프로젝트일 경우 대상 비즈니스는 현업에서 끊임없이 업무 변화를 수반하고 있다. 이렇게 현업에서 변하는 업무를 어느 시점에서 어떻게 반영할 것인지는 대단히 중요한 과제다. 새로운 공장을 건설하는 프로젝트의 경우 주변 환경에 관한 예상하지 못한 변수들이 발생해 프로젝트 진행을 어렵게 할 경우가 있다. 이럴 때도 미처 예상하지 못한 변수들을 어떻게 반영할 것인지는 전체 일정과 자원에 영향을 미치게 마련이다. 대부분 프로젝트에서 처음 작성한 설계도가 바뀌고 있는 실정이며, 이에 대한 대비가 철저할수록 프로젝트의 성공 가능성은 높다. 그리고 프로젝트가 구현되고 실제 사용자가 사용할 때를 대비해 사용자에게 변경된 업무를 미리 알려주고 사용법을 학습하는 행동들을 변화관리라고 정의한다.
프로젝트의 설계 시 설계도가 확정돼 프로젝트 기간 동안 업무 변경이 없다면 변경에 대해 고민할 필요가 없을 것이다. 하지만 대부분 프로젝트는 어느 시점에서 설계도를 그려 프로젝트를 시작하지만 실제 비즈니스 업무는 프로젝트와 상관없이 변경돼 진행되게 마련이다.
이렇게 변하는 업무를 따라잡기 위해 처음부터 신경을 곤두세우지 않으면 나중에 변화된 업무를 추적하기가 쉽지 않다. 이런 변화되는 업무를 추적하려면 '업무변경관리위원회'를 프로젝트 가동과 함께 처음부터 운영해야 한다. 이 위원회가 제대로 운영되려면 해당 업무 비즈니스 의사결정자, IT 관련 의사결정자, 프로젝트 의사결정자 등 실제로 해당 프로젝트와 관련이 되는 각 분야의 의사결정 책임자가 참여해야 한다. 업무가 바뀔 경우 현재 운영되고 있는 업무와 새로운 프로젝트 양쪽의 업무 영향도를 분석해 현행 업무에도 반영할 것인지, 그리고 새로운 프로젝트에도 어떻게 반영할 것인지 결정해야 한다.
이렇게 프로젝트 시작부터 업무 변경에 대비하지 않으면 현행 업무만이 바뀔 경우 프로젝트의 처음 설계도에 있던 업무가 서서히 변해 가는 것을 모르게 된다. 프로젝트의 적용 단계에서 그 차이를 발견하고 원인을 파악하느라 고생하기 마련이다. 그리고 잘못 파악하면 정확한 변경 사항을 모두 반영하지 못하고 에러를 일으키는 중요한 원인을 제공하게 된다. 업무가 바뀔 때마다 업무변경관리위원회를 거치는 게 복잡하고 시간이 걸릴 수도 있지만 결과적으로 전체 시간을 줄이고 에러를 막는 길이다.
일단 프로젝트가 시작되면 사용하는 내/외부 고객에게 프로젝트 진행 사실을 알리고 불필요하거나 사소한 업무 편의를 위한 업무 변경을 자제시킬 수 있는 제도 장치로 활용할 수 있다. 특히 업무변경관리위원회가 형식적이거나 각 분야의 실질적인 의사결정자가 참여하지 않는 형식적인 기구가 되면 업무 변경을 정밀히 추적할 수 없게 돼 프로젝트의 부실을 낳을 수 있다. 우리의 현실을 살펴보면 대부분 프로젝트 부실의 상당수 원인이 업무 변경에 관한 이런 대처를 소홀히 함으로써 생기는 경우를 종종 보게 된다.
프로젝트 출발 시 업무 범위를 확정했는데 프로젝트가 진행되면서 그림처럼 업무가 대부분 변경되게 마련이다. 단기 프로젝트일 경우 이 업무 변경 범위가 작아 큰 영향을 미치지 않지만 중장기 프로젝트일 경우 업무 범위가 최초의 설계 시와 상당히 차이가 난다. 이럴 경우 이런 업무 차이를 어떻게 반영할 것인지는 프로젝트 성패에 영향을 미치는 대단히 중요한 요인으로 작용한다.
업무 변경 차이를 막판에 일시에 반영하는 방법이 있을 수 있고, 프로젝트 기간 중에 몇 단계로 나눠 순차로 반영할 수도 있다. 또 업무가 바뀔 때마다 반영하는 방법이 있을 수 있다. 현실적으로 업무가 변경될 때마다 반영하는 방법은 너무 번거롭고 프로젝트 진행을 더디게 하는 부작용이 있어 채택하기가 쉽지 않다.
남은 두 가지 방법 중 단계별로 반영하는 방법은 단계마다 진행 중인 프로젝트를 잠시 쉬고 설계도를 고쳐서 진행되는 사항과 비교 분석해 업무 변경 요건을 반영해야 한다. 이 방법은 비교적 업무 변경을 주기적으로 반영할 수 있는 장점이 있으나, 일정을 잡을 때 이런 일정을 미리 반영해 두어야 한다. 그렇지 않으면 단계별로 진행 중인 업무를 멈추고 그때까지 변경된 업무를 반영함으로써 그 기간만큼 일정에 차질이 생기게 된다.
마지막으로 변경된 업무를 프로젝트 일정이 모두 마무리된 뒤 최초의 설계부터 그 때까지 변경된 내용을 모아서 반영하는 방법이 있다. 이 방법은 일시에 반영할 수 있는 장점은 있으나 프로젝트 기간이 긴 경우 변경된 업무의 양이 많으므로 설계도에 상당한 변화를 주어 이 시간 자체도 오래 걸린다. 각 방법마다 장단점은 있으나 프로젝트 일정이 짧은 경우와 업무의 변화 폭이 소량일 경우 마지막에 모아서 반영하는 방법이 적당할 것이다. 하지만 프로젝트 일정이 중장기일 경우에는 단계별로 반영하는 방법이 효과적일 수 있다. 업무의 특성과 프로젝트 진행 기간에 변화될 업무량을 추정해 반영 방법을 결정해야 한다.
업무 변경에 대비해 프로젝트의 계획 단계부터 업무변경관리위원회를 가동해 처음부터 변경되는 업무에 대해 철저히 반영하고, 변경 업무를 프로젝트에 어떻게 반영할 것인지 결정하고 진행한다면 프로젝트 성공에 기여하게 될 것이다. 아울러 지금까지 이런 변경 관리 업무를 사소한 추가 업무로 여기고 프로젝트 전체 일정에 넣지 않는 경향이 있었다. 하지만 이제 변경된 업무를 반영하는 것도 프로젝트의 품질을 높인다는 점을 인식하고 일정과 자원을 명확히 배분하고 관리함으로써 성공 가능성을 높일 수 있다.
2. 회의도 관리가 필요한 시대다.
회의로 인해 낭비되는 시간의 가치에 대해서 이야기 하고 있습니다. 회의를 줄이기 위해 단순한 정보 공유는 이메일이나 인트라넷 게시판을 활용하고, 화상회의 같은 것을 충분히 활용하자는 겁니다.
만약 회의를 진행한다면, 미리 회의 목적과 내용을 회의 참석자에게 알리고, 회의의 시작과 끝나는 시간을 정해서 준수하고, 회의 끝 부분에 안건과 결론을 정리하고, 결론이 난 부분을 해당 부서나 팀에 효과적으로 전달해야 한다고 하네요..
회의가 많은 기업은 그리 성공하지 못한다는 이야기를 들은 적이 있습니다. 물론 회의라는 것이 매우 중요한 것이지만 그만큼 잘못 사용하면 탁상공론에 실행이 뒷받침되지 않는 조직이 될 가능성도 높겠죠..
회의관리 전체보기..
오늘도 기업에서 수많은 회의가 새벽부터 밤늦게까지 진행되고 있다. 회의 참석자의 범위와 규모는 회의의 성격에 따라 결정된다. 예를 들어 경영협의회는 경영진을 비롯한 주요 간부가 참석하게 되고, 실무 회의에는 사안에 따라 직/간접으로 연관되는 실무자들이 참석하게 된다. 대부분 기업에서는 의사결정이 필요할 때 폭넓은 의견을 확보하고 수렴하기 위해 관련자들을 모아 회의체를 운영하게 된다.
그런데 회의체 운영 시 참석자들이 미리 검토했어야 할 회의 자료가 회의 직전에야 전달된다든지, 아예 회의 장소에서 배부되는 경우가 잦다. 또 회의 참석자 자신이 참석 이유도 모르고 앉아 있는 경우도 종종 있다. 이런 경우 대부분 주최하는 측의 의도대로 회의 결과가 도출되든지, 충분한 협의를 거치지 않은 상태에서 회의가 중단되거나 졸속 결론으로 회의가 끝나 바람직한 회의 성과를 기대할 수 없다.
직원 1인당 연간 비용(직접 인건비와 직간접 경비 포함)을 5천만 원으로 가정했을 때, 월 근무 시간인 176시간을 기준으로 나눠보면 대략 시간당 2만 4천 원이 쓰인다. 이런 직원 20명이 모여 2시간 회의를 했다면 96만 원이다. 100만 원 가까운 비용이 소비된다. 또 이 직원들이 회의를 하지 않고 영업을 하거나 자기 직무를 수행했을 경우에 발생하는 기회비용까지 계산한다면 훨씬 많은 비용이 회의를 위해 쓰여지고 있는 셈이 된다. 만약 이렇게 많은 비용과 시간이 소요된 회의가 별 성과 없이 진행됐다면 그만큼 회사의 자원을 낭비했다고 볼 수 있다.
이같은 소모적인 회의로 인한 낭비를 막기 위해 회의 참석자들에게 실제로 지급하지는 않지만 계정처리를 할 수 있는 회의비를 각 부서나 팀에 미리 배정해두는 방법이 있다.
예를 들어 A팀에서 연간 사용할 수 있는 이런 회의비로 1억 원을 배정해뒀다고 가정하자. 위의 예와 같이 20명의 인원이 참석하는 정기 회의를 한 주에 3번씩 진행하면 월 1200만 원, 연간 1억 4400만 원이 소요되므로 회의를 축소하든지 참석 인원을 줄여야 한다. 그리고 배정된 경비를 쓰지 않았을 때는 차액의 일정 부분을 인센티브로 전환해 해당 팀이 실제로 사용할 수 있는 경비로 배정해줄 수 있다. 물론 이에 따른 부작용도 있을 수 있지만 불필요한 회의를 억제할 수 있으며, 더 효율적인 회의 방안을 강구해 운영할 수 있다.
물론 이런 물리적인 억제책만으로 회의의 효율을 높일 순 없다. 먼저 기업에서 회의를 하는 목적 중 단순히 정보를 공유하거나 홍보할 목적이라면 굳이 바쁜 직원들을 모아 놓고 회의를 할 것이 아니라 전자게시판이나 e메일을 활용하도록 한다. 국제화?디지털 시대에 맞춰 동일 기업의 조직원들도 근무 장소와 근무 시간대가 각자 다르다. 이런 다양한 근무 형태 탓에 많은 직원이 같은 시간대에 한 장소에 모이기가 쉽지 않다. 요즘 같은 인터넷 시대에 꼭 무리하게 물리적인 공간을 고집할 것이 아니라 화상회의 시스템이나 콘퍼런스 콜 등 가상의 공간을 적극적으로 이용하도록 하면 조직의 능률을 높일 수 있다.
기업 중에 영업을 해야 하는 직원들이 많은 부서는 아예 모바일 오피스를 운용한다. 직원들은 고정된 책상이 없이 필요할 때 와서 비어 있는 책상에서 업무를 수행한다. 정보를 공유할 경우에는 인터넷이나 인트라넷을 통해 처리하고 업무 관련 연락과 지시 사항도 e메일을 통해 처리하는 경우가 많으며, 되도록 함께 모이는 시간은 최대한 줄이는 경우가 많다. 재택 근무를 하는 직종에서도 함께 모이는 회의는 억제되고 공유가 필요한 정보는 전자 수단을 통해 전달된다. 이와 같이 기업에서는 직원들이 많이 모이는 회의를 적극 억제하는 경우를 많이 볼 수 있다.
회의를 해야 한다면 미리 회의 목적과 내용을 회의 참석자에게 알려야 한다. 이때 참석자의 선정도 신중해야 한다. 회의 시 결론을 내야 하는 안건을 분명히 고지해야 한다. 되도록 회의의 시작과 끝나는 시간을 알려 정해진 시간을 준수하는 습관을 가져야 한다. 그리고 회의 끝 부분에 회의의 안건과 결론 부분에 대해 정리해야 한다. 결론이 난 부분은 해당 부서나 팀에 효과 있게 전달해 방안에 그치지 않고 실행될 수 있게 해야 한다. 실행 과정도 피드백할 수 있는 제도 장치를 마련해야 한다. 이렇게 회의의 시작부터 실행까지가 기획되고 투명하게 진행될 때 조직원들은 회의에 진지하게 참석하게 되고 회의는 효율적이 될 것이다.
회의의 시작부터 끝까지 관리해야 회의의 효율화를 기할 수 있다면 기업 내에 회의를 관리하고자 "회의관리자"를 지명해 운영하는 것도 하나의 방법이다. 회의 주최 측에서는 우선 회의관리자에게 회의 장소, 일시, 참석자 명단, 회의 목적과 안건, 결정할 사항 등을 전달한다. 회의관리자는 회의 장소 및 참석자의 참석 가능 여부를 확인, 조정하며 회의를 진행하고 난 뒤 미리 계획된 대로 회의가 진행됐는지, 결론은 도출됐는지 점검하고, 결정된 결론이 실행되고 있는지 사후 관리하게 해 전체 회의체 운영의 효율화를 기할 수 있다. 이렇게 기업 내에서 진행되고 있는 수많은 회의들을 비용?실행?참석자 시간 관리 측면에서 총체적으로 관리하는 회의관리자를 지명, 운영함으로써 조직 전체로 낭비될 수 있는 자원의 손실을 막을 수 있다.
지금 이 시간에도 기업 내의 회의실에서 많은 회의가 진행되고 있다. 과연 몇 명의 직원이 몇 시간씩을 모여 앉아 어떤 결론을 내렸는지 알 수 있거나, 어떤 결론을 내고자 회의를 계획 중인지 예상할 수 있는 기업이 몇이나 될 것인가! 이 글을 읽고 있는 여러분의 회사는 어떻게 회의를 진행하고 있는가. 이 기회에 회의가 진행되고 있는 회의실 뒤쪽에 앉아 있어 보라!!!
3. 이해관계자를 '내 편'으로 만들어라
이해관계자라 하면 고객과 같은 '프로젝트 스폰서', 프로젝트를 수행하는 '프로젝트 실행자', 프로젝트에는 직접 관여하지는 않지만 영향을 주거나 받을 수 있는 '외부 이해관계자'를 이야기 합니다.
이런 이해관계자를 명확하게 파악하고, 각자의 입장에서 프로젝트 수행에 대한 득실과 주장의 정보를 파악하고, 프로젝트에 대한 영향을 분석하고, 대응전략과 구체적인 실행방안을 세우고, 모니터링 및 피드백을 해야 한다는 겁니다.
여기에서는 주로 외부 이해관계자에 대한 이야기를 하고 있는데요.. 저는 일반적으로 IT 프로젝트에 있어서 고객에 초점을 맞추고 싶습니다. 고객이라 하면 외부고객과 내부고객으로 나눠 볼 수 있을 겁니다. 내부에 같이 프로젝트를 진행하는 사람들도 하나의 고객이라고 생각하고 내편으로 만들어 업무를 진행한다면 프로젝트 진행이 좀 더 수월해지지 않을 까 합니다.
이해관계자 전체보기..
최근 우리나라의 각종 국책사업 중 어려움에 직면해 있는 프로젝트들이 있다. 예를 들어 새만금 간척사업과 부안 핵폐기물 처리장 건설사업 등이 있으며, 고속철도나 고속도로 건설의 경우 환경단체의 반대로 건설이 지연되는 경우도 있다. 기업에서도 신제품을 개발할 경우 특허권 분쟁이나 경쟁사의 이의 제기로 프로젝트가 미뤄지는 때도 있다. 이렇게 국책사업이거나 기업에서 추진하는 많은 프로젝트들이 시작 단계나 진행 과정에서 곤란을 겪는 경우가 종종 발생한다. 개인의 경우 주택이나 빌딩을 건축하는 과정에서도 일조권 같은 문제로 건축물 신축 프로젝트의 진행이 난관을 겪는 경우도 허다하다. 왜 이런 문제들이 발생하고 있을까.
어떤 일을 하고자 할 때 직/간접으로 이해 관계가 있는 사람들을 우리는 이해관계자라고 말한다. 쉽게 말하면 어떤 일로 인해 직/간접으로 손해를 보거나 이익을 보는 사람들을 "이해관계자"라고 정의한다. 프로젝트 추진에 관한 이해관계자로는 첫째, '프로젝트 스폰서'로서 기업의 이사회, 임원이나 부서장, 고위 관리 감독자, 외부나 내부의 고객들이며, 프로젝트를 입안하고 궁극적으로 프로젝트가 운영되도록 힘쓴다. 둘째, '프로젝트 실행자'로서 프로젝트 팀장, 팀원, 프로젝트 관련 공급자, 계약자, 전문가, 컨설턴트 등이며 직접적으로 프로젝트를 실행하는 그룹이다. 셋째, '외부 이해관계자'로서 환경단체, 사회단체, 언론, 경쟁사 등이며, 이 그룹은 이론상 프로젝트에 직접 관여하지는 않지만 프로젝트 진행 과정 중이나 결과로 영향을 받는다. 이런 외부 이해관계자들의 영향력이 너무 강력할 경우에 프로젝트 진행이 곤란할 경우도 있다.
프로젝트 초기부터 이해관계자들이 존재한다는 사실을 명확하게 인식하고 출발해야 프로젝트의 성공 확률을 높일 수 있다. 프로젝트를 입안할 때 우선 관련되는 이해관계자가 누구인지 명확하게 파악해야 한다. 이때 제외되는 이해관계자가 없도록 꼼꼼히 살펴야 한다. 이해관계자가 파악됐으면 각자의 입장에서 어떤 이해 득실이 있는지, 그들의 주장은 무엇인지 등 이해관계자에 대한 기초 정보를 수집해야 한다. 그리고 수집된 정보를 바탕으로 프로젝트에 어떤 영향을 미칠 수 있는지 상세히 분석해야 한다. 최종적으로 이해관계자별로 프로젝트에 미칠 수 있는 영향을 파악한 뒤 이에 대한 대응 전략을 세워야 한다. 대응 전략 수립 시 구체적인 실행 방안이 포함되도록 한다. 프로젝트를 진행하면서 실행 과정을 계속 모니터링하고 실행 결과를 피드백하는 일도 놓치지 않도록 한다. 이런 일을 위해 ??이해관계자를 관리할 책임자??를 선정해 체계적으로 관리한다면 더욱 효과가 있을 것이다.
하지만 이해관계자를 체계적으로 관리하는 일은 생각만큼 녹록치 않다. 그 이유는 이해관계자 간의 이해 관계가 단순하지 않다는 것이다. 우선 하나의 프로젝트에도 이해관계자는 다수가 존재하게 되며, 이런 여러 이해관계자 안에서도 그룹별로 이해 관계가 상충될 수 있다는 점이다. 또 이해 관계의 정도에 따라 이해관계자가 프로젝트 진행에 미치는 영향력의 크기에 차이가 나기도 하고 이해관계자 간의 이해 득실이 복잡하게 상호 작용하므로 사안이 단순하지 않다. 우리 사회 전반에서도 예전처럼 이해 관계가 있더라도 침묵하는 것이 아니라 적극적인 의사 표시를 하는 경우가 많아지고 있다. 인터넷 시대로 접어들면서 소수 집단이든 개인이든 의사를 명확하게 표현하는 시대로 접어들고 있다.
이제는 이런 의사 표시에 프로젝트의 진행 측에서도 명확하게 입장을 밝혀야 하는 시대가 됐다. 어떻게 보면 프로젝트의 진행 과정에서 관련 이해관계자들한테 투명하고 명확하게 사실을 밝히고 이해를 구해야 한다. 프로젝트의 종류에 관계없이 이해관계자는 있게 마련이고 대체적으로 모두를 만족시키기는 매우 어렵다. 그리고 이해관계자들이 필요한 정보를 모르고 있다가 프로젝트의 막바지에 알려져 프로젝트의 진행이 멈추어져 더욱 곤란을 받는 것보다는 처음부터 이해관계자들한테 사실을 알리고 충분히 설명하고 이해를 구해서 프로젝트를 진행하는 것이 오히려 시간을 절약하는 길이다. 대체적으로 처음 프로젝트를 설명하고 알릴 때는 사실보다 과장하거나 장밋빛으로 말하는 경향이 많다. 그러기보다는 사실에 가깝게 더욱 보수적으로 얘기하고 솔직하게 접근하는 것이 프로젝트가 진행되거나 종료되고 실행 단계에서 저항을 줄이게 된다.
프로젝트를 진행하려고 이해관계자들에게 여러 근사한 제안을 하거나 요즈음 사회 전반에 이슈가 되고 있는 선거에서도 입후보자가 여러 가지 환상적인 공약을 내걸고 있는 예를 많이 본다. 예전에는 공약은 공약이고, 제안은 제안에서만 잘 말하면 그만이었지만 이제는 사회가 투명해지고 있고 이런 제안이나 공약을 감시하는 사회단체들도 많아졌다. 이제는 이해관계자들이 처음 말한 사실과 실제 집행 과정을 비교 분석하면서 모니터링하고 있다. 섣불리 하면 더욱 곤경에 처할 수 있는 사회가 돼가고 있다. 이제는 처음부터 솔직하게 예상되는 문제점들을 정확하게 말해야 한다. 이해관계자들에게 적당히 얘기하고 넘어갈 수 있는 시대는 지나갔다. 좀 어렵고 시간이 걸리더라도 프로젝트의 시작 단계에서 프로젝트의 내용을 정확히 설명하고 설득해 이해를 구해야 한다. 논리적인 말로서는 약간의 문제가 있지만 요즘 교통방송에서 흘러나오는 '느린 것이 빠른 것이다'라는 캠페인은 프로젝트의 진행 과정에서도 더욱 실감나는 얘기로 들린다.
차라리 이해관계자들에게 대체적인 의견 접근을 이루지 못한다면 프로젝트를 출범하지 않는 게 현명할 수 있다. 우리는 너무 쉽게 이해관계자들을 취급하는 경향이 있다. 출발 전에 이렇게 이해관계자들에게 이해를 구하거나 공감대를 형성해두면 진행 과정에서 문제를 훨씬 줄일 수 있다. 물론 처음에 이해를 구했다고 해서 진행 과정에서 소홀히 해서는 안 된다. 프로젝트의 진행 과정에서도 관심을 갖고 이해관계자들에게 진행 과정을 계속 알려야 한다. 이렇게 해야 이해관계자들이 이 프로젝트의 열렬한 옹호자들이 되어 프로젝트의 성공을 기원하게 된다.
프로젝트의 성공으로 가는 길은 이렇게 험난한 여정이 도사리고 있다. 하지만 외롭게 프로젝트 관련자들만 가는 것보다 프로젝트의 이해관계자들과 동행해서 그들을 우리의 우군으로 만들어 같이 갈 수 있다면 어려운 난관도 쉽게 넘어서 프로젝트의 성공에 이를 수 있을 것이다.
4. 프로젝트 연착륙 뒤엔 변화관리가 있다.
여기에서 변화관리는 위의 변경관리와 다른 이야기 입니다. 변경관리가 프로젝트 진행 중에 발생하는 변경 요소를 관리하는 것이라면, 변화관리는 프로젝트 완료 후 새롭게 적용되는 변화에 대한 관리를 말합니다.
프로젝트를 완료하더라도 적용해야 하는 직원들의 새로운 환경이나 제도에 대한 저항을 받을 수 있다고 합니다. 그래서 실행 과정에서 직,간접적으로 영향을 받게 되는 조직원과 고객으로부터 불편을 사게 되면 기대한 만큼의 성과를 내기도 어렵고, 조직원과 이해관계자들한테 성공했다는 평가를 받기 힘들다고 합니다.
변화를 적극 수용하고 변화에 대한 저항을 극복하며, 변화 계획을 세우고 그 계획을 차질 없이 성취해 나가기 위한 변화 관리가 필요하다고 이야기 하고 있습니다.
실제로 어렵게 프로젝트를 통해 결과물을 만들어도 제대로 활용하지 않으면 무용지물일 겁니다. 결국 만드는 것만이 최종 마무리가 아니라 제대로 필요한 곳에 적용하는 것이 성공적인 프로젝트의 마무리가 아닐까 합니다.
변화관리 전체보기..
우리는 오늘도 어제와 변함없이 같은 장소에서 근무하고 있다고 생각한다. 하지만 우주 공간에서 좌표를 따져보면 어제와 같은 위치에서 근무할 가능성은 거의 없다. 이 우주 공간에서 지구는 태양을 중심으로 자전과 공전을 하고 있고, 물체들은 한순간도 멈추지 않고 내부적인 운동에 의해 변하지만 외부적인 운동으로도 끊임없이 변하고 있다. 이런 변화 속에 모든 물체들은 스스로 생존을 위한 노력과 관성에 의해 움직이고 있고, 모든 생물은 변화하는 환경에 적응하려고 노력한다. 이런 노력을 하지 않거나 포기한 생물은 점차 도태되거나 사라지게 되는 자연의 법칙을 우리는 배운다.
대부분 사람들은 어제까지 배웠던 지식을 오늘도 활용하고 싶어하며, 익숙한 행동을 하는 것에 편안함을 느낀다. 물론 로버트 풀검이 지은 책 <내가 알아야 할 모든 것은 유치원에서 배웠다>라는 제목처럼 한번 배운 것을 평생 사용할 수 있다면 얼마나 편하고 좋을까. 하지만 어제의 지식이 오늘 새롭게 변하는 환경에 적응하지 못하고 더 이상 유효하지 못하는 세상이 도래하고 있다. 이런 변화는 지금까지 배웠던 지식을 뒤로하고 새로운 것에 관한 학습을 요구하며, 새로운 것에 신속하게 익숙해질 것을 강요한다. 힘들게 배워서 적응할 만하면 또 변화하므로 늘 새로 배워야 한다는 부담은 사람들을 두렵게 만드는 요인으로 작용하며, 변화에 저항하게 하는 요인으로까지 작용하게 된다. 기업에서 비즈니스 프로세스 리엔지니어링(BPR)이나 전사자원관리(ERP), 연봉제, 새로운 원가관리시스템의 적용과 같은 많은 경영 혁신 기법들이 좋은 의도로 출발하나 실패하는 경우를 종종 보게 된다. 이렇게 실패하는 배경에는 조직원의 새로운 환경이나 제도에 대한 저항이 도사리고 있는 경우가 많다.
오늘날 기업들은 급변하고 있는 경쟁 환경 아래 시시각각 변하고 있는 고객의 마음, 경쟁사의 동태와 기술의 발전을 따라잡고자 애쓴다. 고객의 욕구에 맞는 제품이나 솔루션 또는 서비스를 제공해 경쟁 기업보다 더 많은 고객들을 확보하고, 나아가 치열한 경쟁에서 살아남으려고 노력한다. 이런 고객의 욕구를 더욱 빠르게 파악하고 변화에 대비하고자 여러 가지 경영 기법을 사용하기 위해 프로젝트를 수행하게 되며, 그 결과로서 기업 내부의 시스템이나 조직을 더욱 유연하게 만들게 된다.
이 시각 현재 기업에서는 경쟁력 향상 및 수익성 제고 등을 위해 ERP, 고객관계관리(CRM), 공급망관리(SCM) 등 각종 비즈니스와 IT 프로젝트를 수행하고 있다. 이런 프로젝트는 기업 내부 프로세스뿐만 아니라 조직상의 변화를 가져오게 되며, 폭넓게는 기업 문화 및 외부 이해관계자까지 영향을 미치게 되고, 조직원들에게는 큰 변화를 요구하게 된다.
대부분 IT 프로젝트 팀은 계획된 일정과 예산 아래 프로젝트를 성공리에 마치고자 프로젝트 수행에 모든 역량을 집중하게 되며, 프로젝트와 관련돼 일어날 변화에 대해 정작 알아야 할 조직원들에게는 상대적으로 대응을 등한시하게 된다. 어떤 프로젝트든지 크든 작든 그 프로젝트를 실행하는 과정에서 현재의 프로세스와 다른 변화가 뒤따르게 되며, 프로젝트 성과는 이해관계자의 변화 수용의 정도에 영향을 받게 된다. 프로젝트 종료 후 실행 과정에서 직/간접적으로 영향을 받게 되는 조직원과 고객으로부터 불편을 사게 되면 기대한 만큼의 성과를 내기도 어렵고, 조직원과 이해관계자들한테 성공했다는 평가를 받기 힘들다.
IT 프로젝트의 성과는 프로젝트 결과에 직/간접적으로 영향을 받게 되는 조직원들의 의식 구조와 업무 방식이 변해야 나타난다. 따라서 변화를 적극 수용하고 변화에 대한 저항을 극복하며, 변화 계획을 세우고 그 계획을 차질 없이 성취해 나가기 위한 변화 관리가 갈수록 중요해지고 있다. 이에 IT 프로젝트팀 구성 시 따로 변화 관리를 전담할 수 있는 이른바 '변화관리 추진조직'을 구성해 프로젝트 초반부터 변화 관리를 도맡도록 하는 게 바람직하다.
변화관리팀은 변화 관리에 대한 계획을 세우고 커뮤니케이션과 교육 및 훈련을 통해 운영하며, 그 결과를 평가해 성과를 보상해줌으로써 IT 프로젝트가 연착륙할 수 있는 중요한 역할을 맡게 된다. 변화관리팀의 역할은 첫째, 이해관계자 관리를 수행한다. 변화 스폰서의 지원을 가시화하고 조직원의 참여와 변화의 수용도를 높이고자 스폰서십 구현을 지원한다. 둘째, 프로젝트의 활성화를 꾀한다. 프로젝트 추진팀의 구성부터 프로젝트 추진에 전념할 수 있는 환경 조성을 위한 활동을 수행하며, 프로젝트 추진 성과에 대한 모니터링을 수행한다. 셋째, 조직원의 변화 관리 계획을 수립한다. 다양한 정보 분석을 통해 변화의 준비 상태를 평가하고 그 평가 결과를 활용해 변화 관리 계획을 수립한다. 넷째, 조직 역량에 관한 변화 방안을 세운다. 새로운 시스템 구축에 따른 프로세스 및 업무 양식의 변화를 위해 조직 구조 재설계와 바람직한 조직문화 형성을 위한 방안을 수립한다. 다섯째, 성과 관리 및 보상 체계를 수립하고 운영한다. 변화 관리 활동의 성과를 평가해 그 결과를 보상과 연계한다. 여섯째, 커뮤니케이션 활동을 통해 조직원들이 겪을 수 있는 변화에 대한 저항을 없애면서 변화에 순응할 수 있게 한다. 프로젝트 진행 과정에서 발생하는 프로세스, 시스템 및 조직상의 변화 방향에 대한 조직 구성원의 긍정적인 인식을 확보하려면 이해관계자별로 다양한 커뮤니케이션 채널을 활용해 수행한다. 일곱째, 교육과 훈련을 통해 조직원들을 변화에 적응시킨다. 프로젝트에 따른 업무 변화와 프로젝트의 활용 능력을 극대화해 조직원들의 시스템 이용률을 높이게 된다.
지금 이 시각에도 많은 기업 내부에서 IT 프로젝트가 진행되고 있으며, 프로젝트의 시작을 '우리는 매우 중요한 새로운 프로젝트에 착수합니다. 우리는 진정으로 이것이 중요한 일이라고 생각합니다'라는 메시지를 보내면서 시작하고 있다. 하지만 조직원들은 이 메시지에 쉽사리 관심을 기울이지 않는다. 이것이 변화관리팀이 직면하고 있는 어려움이다. 즉 그들은 사려고 하지 않는 사람들에게 뭔가를 팔아야 한다. 그들이 팔고자 하는 것은 변화이고, 사기를 주저하는 구매자들은 기업 내부의 사람들이다. 하지만 어렵다고 변화 관리 활동을 게을리 한다면 많은 프로젝트는 실행 과정에서 난관에 부딪치게 될 것이다. 이런 어려움을 극복하고 기업 생존을 위해 프로젝트를 수행한다는 것을 부단히 알리고 체계적으로 설명한다면 조직원들도 훨씬 적극적으로 변화를 수용하고 프로젝트의 성공에 동참할 것이다.
