전사전략: 기업 방향성 부여 (전략기획)

전사전략

기업에 방향성을 부여하는 방법은 일반적으로 크게 세 가지이다. 첫째. 방향을 표명한다. 경영이념이나 기업의 미션을 명확하게 제시하거나 회사의 미래 모습을 구체적으로 그린다. 둘째. 어떤 사업 분야에 진출할 것인지를 구체적으로 밝힌다. 셋째. 기업 내부에서 키우고자 하는 능력을 분명히 한다. 이를 통해서 기업 전체의 공통 사항을 정의, 공유하여 기업이 제각기 움직이는 조직의 집합이 아닌 일관성을 지닌 하나의 조직임을 만들어 나가야 한다.

 

1. 경영이념, 비전, 미션

앞서 경영이념이나 비전은 기업의 존재 의의나 수행해야 할 미션을 보편적 형식으로 표현한 기본 가치관이라고 했다. 경영이념은 어떤 자세로 경영에 임할 것인지를 명확히 한 것이고 비전은 기업이 추가하는 장래의 구체적인 모습을 여러 이해관계자에게 표명한 것이다. 이는 전략기획의 전제가 되기 때문에 기업경영에 미치는 영향이 매우 크다. 즉 기업 구성원의 의욕을 북돋는 끔(희망)을 심어주고 기업 구성원에게 행동규범을 부여하며 궁극적으로는 사업 성공의 열쇠가 된다.

기업의 규모가 커지고 사업 분야가 다양해질수록 조직의 힘을 하나로 합치는 명확한 경영 지침이 필요하다. 살펴본 바와 같이 경영이념이나 비전, 미션은 중첩도 되며 헷갈리는 부분도 많다. 그래서 때에 따라선 그 의미를 굳이 구분하지 않고 사용하기도 한다. 중요한 것은 기업의 근본 방침을 명확히 나타내는 것이다. 올바른 경영이념과 비전을 정하고 그것을 철저히 지키려고 노력하는 것은 매우 가치 있는 일이다. 어떤 방법들이 최선이라고 할 수는 없지만 최고경영자가 문제의식을 가지고 몰입하고 실천하는 것이 가장 중요하다. 더불어 시간의 흐름에 따라 경영이념이나 비전을 다시 설정하고 관리해야 한다. 영원한 것은 없고 고수할 필요도 없다.

경영이념

  • 기업의 경영이념을 유지하면서 조직을 하나로 만드는 방법은 무엇보다도 사업을 성공시키고 조직원들에게 경영이념을 주지시키는 것이다. 즉 행동의 결과물로 명확하게 보여주고 체험할 수 있게 만들어야 한다. 이 속에서 조직에 자신감과 확신을 심어주어 성공의 선순환 구조를 구축하는 것이다. 또한 여러 매체를 활용하는 것이다. 이를 통해서 공신력을 심어주고 접근성을 강화하여 최고경영자의 의지를 계속 대면토록 해야 한다.

  • 기업의 방향은 전략 전개의 대전제가 되고 경영에 직접적 영향을 미친다. 그래서 경영이념에 대한 추진과 결과를 보면서 필요하다면 재정의해야 한다. 제대로 조직에 전달되고 있는지 확인하고 점검한다.

경영계획구조

< 경영계획 구조 예 >

 

2. 사업영역 결정

사업영역을 고객과 기술, 시장과 제품/서비스 측면과 자사의 고객 제공 기능의 3가지 축으로 그려보면 새로운 시각을 얻을 수 있다. 예를 들어 과거 미국의 철도회사는 사업을 철도로만 정의하고 수송이라는 기능의 축을 정의하지 않아서 이후에 등장하는 트럭이나 비행기 등과의 경쟁에서 뒤처졌다. 시대가 변화하면서 고객의 니즈를 파악하고 사업영역을 확대, 수정해 가는 노력은 지속적이어야 하며 이와 동시에 시너지효과와 범위의 경제를 고려해야 한다. 그리고 실행이 필요한데 쉽지 않다. 특히 융합의 일상이 된 요즘에는 그 경계선을 긋는 것조차 무의미한 경우도 있다. 그럼에도 불구하고 이러한 여러 요인들을 고려하고 심사숙고하여 사업영역의 범위를 정해야 한다.

사업영역

 

3. 핵심역량의 선택과 육성

핵심역량(Core Competence)이란 기업의 방향을 설정하는 중요한 방법 중 하나이다. 이는 기업에서 장기적으로 개발해 나가는 능력, 즉 기업의 능력이라고 할 수 있는데 이를 Capability 또는 Skill이라 한다. 미국의 경영 컨설턴트인 게리 P. 하멜과 경영학의 예언자로 불린 C. K. 프라할라드 교수는 핵심역량을 ‘고객에게 타사가 흉내 낼 수 없는 자사만의 가치를 제공하는 기업의 핵심적인 힘’으로 정의하는데 자원 준거 이론의 근간이 또 이 핵심역량이다.

핵심역량

핵심역량은 기업의 업태, 업종에 따라 다양하고 그 기업의 가치관과 철학에 따라서도 모두 다르며 정답은 없다. 핵심역량은 보통 경쟁우위를 제공할 수 있는 능력, 다른 기업에서 쉽게 모방할 수 없는 능력, 기업의 모든 활동에 널리 적용될 수 있는 것, 그리고 기업의 성장과 발전을 촉진할 수 있는 힘으로 특징지을 수 있는데 이를 바탕으로 각자 자신에게 맞는 핵심역량의 정의를 해야 하는데 크게 기존 다른 회사와 다른 비즈니스모델을 개발하고 관리하는 능력, 새로운 방식의 조직을 운영하는 능력, 세상의 변화에 살아남기 위한 기술력을 손에 쥘 수 있는 관점에서 정의를 해봄 직하다.

 




4. 전사전략과 리더십

리더는 외롭다. 그 어깨 또한 무겁다. 하지만 그 길을 가기로 했다면 여러 가지 역할을 수행해야 하는데 몇 가지를 살펴보면 다음과 같다.

  • 자원, 능력, 전략적 지위, 조직의 체질 등을 최대한 활용하여 사업에 성공할 수 있는 비전을 제시한다.

  • 제시한 비전이 현실적이고 실현 가능하다는 점을 명시한다. (특히 정량화된 숫자와 시점 설정이 중요하다.)

  • 이 비전이 조직에 스며들고 실현될 수 있도록 모든 노력을 아끼지 않는다.

이렇듯 리더는 역할 수행에 있어서 관리능력뿐만 아니라 그 뒤에 있는 리더십을 발휘해야 한다. 이는 정성/정량의 협치이며 사람으로서의 매력을 나타낼 수 있다. 이를 통해 추진력에 불을 붙이고 앞으로 나아가야 한다. 아무리 훌륭한 리더도 모르는 것이 있을 수 있다. 따라서 혼자 모든 것을 해결하려고 하면 안 된다. 필요하면 도움을 요청하고 사람을 활용하여 기업의 방향에 영향을 끼치지 않도록 해야 한다. 리더는 깃발을 놓치지 않아야 한다. 깃발을 질질 끌거나 한 곳에 계속 방치해 두면 조직은 와해된다. 이를 해결하는 역할 또한 리더의 리더십이다.

리더는 리더십이 있어야 한다고 하는데 관리가 아닌 선도를 위해서는 불확실한 미래를 내다보고 앞서 나아가야 하는 어려운 일이다. 이는 의사결정도 중요하지만 전략을 실행하는 실행력이 가장 큰 몫을 한다. 전략은 시장만 아니라 기업 내에서도 실현할 수 있어야 한다. 전략 변경의 범위나 순서도 조직의 힘에 따라 변할 수 있기 때문이며 전략은 의사결정에 필요하다기보다는 적합한 방향을 부여하고 실천하는, 어쩌면 의사결정보다도 중요하다. 그래야 의사결정을 다시 재수정할 수 있기 때문이다.

전략수립의 요건 3가지 (전략기획)

전략수립의 요건: 분석, 실행 그리고 전환

들어가며

전략이라는 단어가 흔한 오늘날, 진정한 전략의 의미와 가치를 다시 한번 되짚어볼 필요가 있다. 1960년대 미국 대기업들의 사업 다각화와 함께 본격적으로 주목받기 시작한 전략이란 개념은 점점 더 복잡해지는 비즈니스 환경에서 그 중요성은 높아지고 있다. 그렇다면 전략이란 정확히 무엇인가?

 

1. 전략. 그리고 전술과 전투

구분 군사(국가/군) 기업(CEO) 부서장/팀장
전략 장기적 전쟁 전체 목표·방침, 방향 기업 비전·장기목표, 경쟁우위 확보를 위한 전체적 방향 설정 부서/팀의 중장기적 목표, 업무방향 설정
전술 구체적이고 단기적인 작전·병력 운용 계획 구체적 실행계획·실무 방법 업무 분장·실행 방안, 일정관리
전투 실제 교전·작전 실행 현장 실적·업무 실행, 실적달성, 고객응대 실무자의 일상 업무, 과업 수행
 
전략은 2,500여년 전 전쟁을 치루면서 다뤄진 군사용어가 그 기원이라고 한다. 전쟁에 승리를 하기 위해 군대를 배치하고 운영하는 이련의 계획을 뜻했던 전략은 시간이 흐르면서 전쟁 뿐만 아니라 경영, 정치, 스포츠 등 우리 주변의 모든 분야에서 목표 달성을 위한 체계적인 계획과 행동을 담는 함의적인 단어로 사용되고 있다.
 
여기서는 전략을 경영적 관점에서 기업, 회사, 조직 내에서 주로 다루고자 한다. 위 표에서 보듯 원 기원의 목적은 다음과 같다.
  • 전략: “왜”, “무엇을” 할 것인가에 대한 큰 그림을 뜻한다.
  • 전술: 전략을 기반한 “어떻게” 할 것인가에 대한 구체적 실행 계획을 말한다.
  • 전투: 전략과 전술에 의거한 “실제로 무엇을 했는가”에 대한 행동을 나타낸다.

이를 현대적 관점에서 핵심적 요소로 부면 목표, 수단, 방법을 말하며 전략의 목표는 달성하고자 하는 바이며 수단은 목표 달성을 위해 활용할 수 있는 자원, 그리고 방법은 목표와 수단을 연결하는 실행 방식으로 어떤 경로와 방식으로 자원을 투입할지에 대한 선택과 집중을 뜻한다.

“전략은 목표와 수단, 그리고 실행이 포함된 것이며, 남이 쉽게 파악하지 못하는 독창적인 특성이 있다. 장기적으로 한 조직이 추구하는 방향이며, 외부 환경 및 내부 능력에 대한 분석을 바탕으로 자원과 노력을 특정한 방향으로 집중시키는 효율적 방안을 모색하는 과정이자 실행계획을 세우고 실천하는 전 과정이다.”

 

2. 전략의 본질과 관점

전략적 의사결정의 핵심

이러한 전략을 기반한 기업/회사에서의 전략적 의사결정은 일반적으로 기업이 나아가야 할 방향에 대한 판단이다. 모든 기업에게 생존과 성장은 가장 중요한 과제이며, 이를 위해서는 명확한 경영의 방향성을 바탕으로 한 모든 사업분야와 전개방식을 사전에 결정해야 한다. 그래서 전략 수립에서 가장 중요한 것은 선택과 집중이다. 경영자원은 언제나 유한하기 때문에 그 중에서 무엇을 버리고 무엇을 취할 것인가에 대한 엄격하고 올바른 판단이 절실하다. 이는 결국 경쟁에서 승리하기 위한 방법론이기도 하며 기업 내 경영진에게는 매우 중요한 과업이다.

전략의 수명과 전환 요구 요인

전략은 영원하지 않다. 아무리 잘 짜여진 전략이라도 그 수명이 반드시 존재한다. 성공한 기업이라도 전략은 상황과 변화에 따라 변경하고 변경해야 한다. 그런 주변의 환경적 요소들은 보통 다음과 같다.

  • 대내외 규제 변화 (완화 또는 강화)
  • 기술 변화와 신기술의 등장
  • 소비자 행동 변화
  • 경쟁기업의 움직임
  • 국제적 경쟁환경 변화
  • 정보기술을 포함한 사회적 인프라 변화

이러한 요소들 중에 특히 규제는 기업 입장에서 기업 전략의 근본을 뒤엎는 중요한 요인 중 하나이다. 이는 기업이 감내할 수 있는 범위 밖에서 흔히 일어나고 통제할 수 없는 부분들이 많기 때문에 전략 전환과 수명에 큰 영향력을 행사한다.

 

3. 전략의 계층과 구성 요소

전사전략 차원에서의 사업 정의

기업은 사업을 다각화할 경우 개별 사업전략 이전에 전사적으로 다음 사항들을 결정해야 하고 이는 각 구분별 사업의 정의가 된다. 

  1. 사업 포트폴리오 목적 결정: 여러 사업을 구상할 때 각각의 명확한 이유를 설정한다.
  2. 도메인 결정: 사업영역 또는 기업 범위를 결정하고 그 시너지효과를 극대화한다.
  3. 사업 포트폴리오 균형 도모: 제한된 자원을 최적 배분하기 위한 노력!
  4. 장기적 성장과 가치 창출: 기업의 비전과 중장기 목표 달성을 위한 신사업 진출, M&A 등 다수의 성장전략을 수립한다.

기업의 적절한 사업 포트폴리오는 조직 내 각 사업 부문에서 공통 활용 가능한 요소들을 통해 범위의 경제를 실현할 수 있다. 이렇듯 기업이 목표로하는 사업은 우리 회사는 무엇을 하고 어디에 집중하며 각 사업은 어떤 역할을 가지며 자원들은 어떻게 배분할 것인가에 대해서 거시적으로 결정하는 것이다.

 

4. 경영이념, 비전과 전략의 관계

경영이념, 비전, 전략 관계

경영이념

창업자나 경영자가 가지고 있는 경영에 대한 보편적 신념, 가치관 및 기업의 이해관계자와 사회에 대한 약속이다. 이는 기업이 존재하는 근본적인 이유(목적)와 신념을 담고 있으며 기업의 일관된 행동과 의사결정의 기준이 된다.

비전

위와 같은 경영이념에 근거해 기업이 추구하는 미래 모습을 구체적으로 제시하는 것이다. 비전은 “우리 회사가 앞으로 어떤 모습이 되고 싶은가?”, “어떤 위치에 도달하고 싶은가?”에 대한 답을 담는 그릇이다.

전략

기업의 기본 가치관을 구현하는 구체적인 방법론으로서 지속적 경쟁우위를 확보하기 위한 기본적인 틀이다. 그래서 경영이념을 뿌리라고 하면, 비전은 그 위에 자라난 미래의 열매, 전략은 이를 실현하는 구체적 방법론을 뜻한다.




5. 전략수립 프로세스

1단계: 외부분석과 내부분석

전략 기획을 위한 명확한 의사결정을 위해서는 체계적인 분석이 필요하고 이를 위한 방법으로 다음과 같은 방식들이 있다.

  • 거시환경분석: 사업에 폭넓게 영향을 미치는 요인들을 파악한다. 이는 기업의 경영 활동에 영향을 미치는 외부 환경 요인, 즉 정치, 경제, 사회, 기술, 법률, 환경 등의 여러 요인을 분석하는 것으로서 이를 통해 기업은 시장 기회와 위협을 파악하고 전략을 수립하는 데 중요한 기반을 제공해 준다.
  • 3C분석: 3C, 즉 시장/고객(Customer), 경쟁사(Competitor), 자사(Company)를 분석하여 마케팅 전략 수립의 기반을 마련하는 기법으로서 이를 통해서 기업은 시장 환경을 이해하고 자사의 강점과 약점을 파악하여 경쟁 우위를 확보할 수 있도록 한다. 

위와 같은 분석의 핵심은 자사의 행동실천과 관련한 가설을 세우고 검증하는 것이며 문제의식을 명확히 하는 것으로서 이는 궁극적인 전략기획의 열쇠가 된다.

전략수립 프로세스와 요소

 

2단계: 대안 마련을 위한 상세분석

전략기획은 기업의 최하단에서 최상단까지 경영 전체를 통합하는 과정으로 매우 지난하고 오랜 시간이 걸릴 수 있다. 그래서 최선의 전략 선택을 위해서는 다음과 같은 과업을 성실히 수행해야 한다.

  1. 경제성 분석에 관한 정량적 파악
  2. 마케팅의 장단점 추정
  3. 의사결정 후 시나리오와 리스크 판단

이를 통해 기업/조직의 관점에서의 모든 현상을 세밀히 파악하고 이해관계자들 간 긴밀히 공유하여 조직 내 전략 인식을 하나로 정리하고 통일해야 한다. 어렵지만 해야하고 반드시 해내야 한다.

 

6. 전략 전환의 타이밍

전략의 성공 여부 판단은 일반적으로 쉽지가 않기 때문에 진행하면서 주요 시점별 평가와 결과에 따른 전략의 전환 고려가 필요하다. 이에 따라 전략의 수정은 전략을 수립하는 기간보다도 더 빠르게 단기간에 이뤄져야 하며, 변화가 극심한 대내외 경영환경과 이에 더욱 영향을 많이 받는 업계, 업종의 경우 전사적으로 전략에 대한 정기적(일반적으로 연단위) 롤링 플랜을 수립하고 진행해야 한다. 다시 말해 전략은 처음 수립한 것을 끝까지 밀고가는 것이 아니라 지속적인 관리가 병행되어야 하면 전략의 전환은 항시 측정하고 평가하여 그 때를 찾아 실행해야 함을 이야기한다.

 

마무리

진정한 전략은 분석과 계획을 넘어 실행으로 이어져야 한다. 실행은 조직 전체의 진취적인 도전정신, 과감한 결정, 빠른 속도, 강력한 추진력과 함께 대표이사 및 경영진의 직접적이고 적극적인 관여(Hands-on), 이를 지원하는 시스템, 업무환경 개선, 조직 분위기의 쇄신이 강건하게 뒷받침되어야 한다. 이를 바탕으로 수많은 전략 중 전략은 선택되는 것이며, 이를 위해서는 최종적으로 경영자의 강한 의지가 또한 필요하다. 이 굳은 의지가 없다면 모든 것은 무용지물이 된다. 그래서 의사결정에는 trade-off가 따르며, 완벽한 전략은 결코 존재하지 않는다. 답은 정해져 있으나 정말로 중요한 것은 불확실성과 여러 리스크 속에서도 올바른 방향을 설정하고, 조직 전체가 한마음으로 실행해 나가는 것이다.

감리 (프로젝트 성공률 1% 높이기)

감리

정보시스템 및 프로젝트 감리는 외부인의 객관적 시각에서 수행되는 프로젝트라고 볼 수 있다. 이러한 감리의 영역은 프로젝트 단계별 및 전문영역별로 다양하지만 목적만큼은 동일하다. 여기서 잠깐 짚고 넘어갈 것은 감리와 감사의 차이다.
 
간단하게 감리(監理)는 감독하고 관리하는 것, 영어로는 supervision이며 감사(監査)는 감독하고 검사하는 것, inspection을 말한다. 다시 말해 감리어떤 사업이나 프로젝트가 기본 계획 및 설계대로 되고 있는지, 효율성, 신뢰성, 품질보증 등의 기술적 요건이 보장되고 있는지를 피감리인의 이해관계로부터 독립된 제삼자가 감독, 지도, 평가하는 것을 말하며 진행 적 성격을 지니고, 감사는 보통의 회계감사와 같은 의미에서 어떠한 조직의 업무에 대해서 제삼자가 업무의 적부 정도를 검토하고 완료된 행위 대상으로 지적, 비판, 시정을 하는 행위로 사후적 성격을 나타낸다.
 
정보시스템에서 있어서 감리, 감사의 대표적 기구는 미국의 정보시스템감시통제협회(ISACA: Information Systems Audit and Control Association)로 IT 거버넌스에 중점을 두고 있는 기관이며 이곳에서 시행하는 국제자격증이 정보시스템감사사(CISA: Certified Information Systems Auditor)이다. 다시 말해 감리는 내부감사의 직무 만에 국한되지 않고 정보화 컨설팅 활동으로서 감사를 포함, 확대한다.
 




 

감리기준

감리인이 감리업무를 체계적으로 수행하기 위해선 표준화된 지침이 필요하다. ISACA에서는 이를 위해 일반기준, 독립성 기준, 기술기준, 감사업무 기준, 보고기준 이렇게 5개 분야의 지침을 제공한다. 이 기준들의 목적은 감사인에게 전문직업윤리강령에 규정된 전문가의 책임을 충족하도록 최소한의 요구사항을 규정하는 것이며 경영자층과 다수 이해관계자에게 감사인의 업무에 관한 직업상 기대 수준을 공지하는 데 있다.
 
🚩 일반기준
  – 자격 및 능력: 전문적 지식과 능력을 갖춰 감사 업무를 수행하며 상황에 따라 적절한 주의와 신중성 발휘
  – 전문성: 공정하고 무결한 행동을 유지하고 감사 업무에 관한 비밀 보호
  – 객관성: 감사 대상과 관련된 이해관계나 영향을 회피하고 독립성 유지
 
🚩 독립성 기준
  – 조직적 독립성: 조직 내부에서 영향력 있는 위치가 아니며 조직의 목표와 이해관계로부터 독립성 유지
  – 개인적 독립성: 감사 대상 및 관련 당사자와의 개인적 관계를 피하고 객관적 업무 수행
 
🚩 기술기준
  – 계획 및 감사 수행: 감사 계획 수립, 감사 업무를 실시하여 목표 달성을 위해 충분한 근거 수집
  – 관련 법규와 규정 준수: 관련 법규와 규정을 준수하고 이에 대한 평가 수행
 
🚩 감사업무 기준
  – 적절한 증거의 획득: 감사 업무를 위해 적절하고 신뢰할 수 있는 증거 획득
  – 관련성 평가: 획득한 정보를 평가, 감사 목적과 관련 있는지 판단
 
🚩 보고기준
  – 감사보고서 작성: 감사 결과를 명확하고 객관적으로 보고서 작성
  – 결과의 명시: 감사 결과에 기반하여 결론 명시
  – 발견된 결함과 건의 사항 제시: 발견된 결함과 개선을 위한 건의 사항 제시
 
특히 CISA는 감사업무를 수행할 때 ISACA의 감사지침인 COBIT(Control Objectives for Information and related Technology) 프레임워크를 참고한다. 이 COBIT은 이전까지의 통제목적이라는 이름으로 정리되었던 것을 경영진이나 정보시스템 실무자 및 감리자에게 유용하게 쓰일 수 있는 포괄적 통제체계로 정립한 것으로 비즈니스 목표와 정보시스템 간의 연결을 강조하고 정보시스템과 관련된 위험을 관리하고 통제하는 데 도움을 준다. 
 
COBIT 2019
< COBOT 2019: 최신판 >
 
 

감리단계 및 절차

정보시스템 감리는 보통 계획, 수행, 보고, 후속 조치의 단계를 거친다. 
 
✔️ 계획수립
: 감리계획은 피감리 조직의 현황, 목적, 감리현황, 위험, 기간 및 비용, 기법/도구 등으로 고려하여 수립한다. 특히 감리목적을 명확히 파악하여야 하는데 감리 요청 시 피 감리인은 감리의 목적을 명확히 하고 감리를 요청하는 것이 일반적이나 그렇지 않은 경우도 많다. 이러한 목적이 불명확한 경우 추후 작업 진행 및 목표 달성에 큰 장애가 될 수 있으므로 반드시 목적과 목표를 명확히 하여야 한다.
 
✔️ 감리 수행
: 감리의 실질적 활동으로서 예비조사를 수행한다. 이를 토대로 감리자료를 확보하고 검토한다. 또한 세부적 감리 일정과 범위를 피감리인과 협의, 조율하며 감리인별로 점검항목과 평가 방법을 준비한다. 감리 수행은 감리 대상과 환경을 이해하고 감리 분야별 점검항목에 대해 검토하고 시험하는 데 의의가 있으며 수행 결과로 문제점과 위험요인을 식별, 개선사항을 도출하고 권고안을 토의한다.
 
✔️ 보고서 작성
: 감리 활동의 결과를 감리보고서로 문서화하는 단계이다. 감리보고서는 매우 복잡한 기술적 사항들에 대해서 구체적인 지적, 권고사항을 도출, 정리하여야 하므로 초안 작성 후 관련자와 세밀한 검토를 거쳐 최종 보고서를 작성하는 형태로 진행한다. 감리책임자는 보고서 취합 후 총평을 작성하고 총평과 감리보고서의 의견이 상이한 경우 총평에 그 차이점을 명시한다.
 
✔️ 후속 조치
: 감리보고서 배포 후 기록보관, 폐기, 지적사항에 대한 개선 확인과 추적관리, 감리문제점 및 미결사항에 대한 시정조치와 추적, 감리인 평가활동 등을 수행한다.
 
 
 
 
※ 애로사항
제3자의 자격이라는 것이 장단점이 있으나 무엇보다도 기존 조직에서 감리인을 대하는 태도는 사전에 충분히 짐작해 볼 수 있다. 하지만 일을 진행하다 보면 비협조적이고 부정적인 분위기와 여러 이해당사자들, 이로 인한 불충분한 자원 및 지원의 문제, 의사소통의 어려움이 전부 다라고 해도 과언이 아닐 것이다. 일의 규모, 전문성 및 복잡성 등 여러 사항 이전에 무엇보다도 사람이 가장 기본인 것은 어디를 가도 마찬가지이다. 사람을 먼저 얻는 방법. 아마도 보다 경청하고 먼저 다가가서 진심을 전하지 않으면 안 될 것이다. 그리고 설득의 도구로서 현실적 전문성을 갖추는 일은 당연하겠지. 이 또한 감리인만의 문제는 아닐 것이다.

PERT/CPM (프로젝트 성공률 1% 높이기)

프로젝트 일정

프로젝트는 비반복적으로 하나의 제품이나 서비스를 생산하는 과업이다. 프로젝트는 우리 주변의 대규모 사업부터 일상생활에서 흔히 일어나는 작은 규모의 사업에 이르기까지 매우 다양한 형태가 존재한다. 그중 대규모 사업의 경우 자원과 시간을 소모하는 수많은 상호 관련성을 갖은 많은 활동으로 구성되어 있어서 이를 성공적으로 수행하기 위해서는 구성 활동들의 체계적 관리가 필요하다.
 
이런 큰 규모의 사업, 즉 프로젝트를 계획, 조직화하여 통제하는 것을 그간 프로젝트 관리라고 하였고 이 관리기법 중의 하나를 일정계획 중에서 PERT/CPM이 널리 사용되고 있다고 하였다. PERT(Program Evaluation and Review Technique)는 1958년 미 해군과 록히드사 및 기타 컨설팅사들이 공동으로 폴라리스 해저 유도탄을 조속히 완성하는 데 사용하고자 개발하였다. CPM(Critical Path Method)는 1957년 미 듀퐁사에서 활동 시간이 확실한 공장건설계획을 수립하기 위해 레밍턴 랜드사와 공동으로 개발하였다.
 
오늘날 이 PERT와 CPM은 모든 프로젝트의 활동 시간 관리와 완료 기간을 계획, 통제하는 기능을 포함하여 관리하는 주요 기법으로 널리 사용되면서 상호 구분이 점점 어렵게 되어 이 두 기법을 ‘PERT/CPM’으로 통칭하여 부르고 있다. 우리나라에서는 1966년 광주 미군 비행장 활주로 공사에 처음 이 기법이 도입되어 사용되었으며 이후 급속히 보급, 활용되고 있다.
 
 

프로젝트 네트워크

PERT/CPM은 대규모 프로젝트를 효율적으로 수행하기 위해 프로젝트를 구성하는 활동 상호 간의 전후 관계를 표시한 프로젝트 네트워크를 사용, 프로젝트를 계획하고 통제하는 기법이다. 여기서 언급한 프로젝트 네트워크는 프로젝트를 시각적으로 표시하기 위해서 그려진 원으로 표시되는 노드와 화살표로 표시하는 가지로 구성된 네트워크를 지칭한다.
 

프로젝트 네트워크

< 프로젝트 네트워크 예 >

 
 
이 프로젝트 네트워크는 프로젝트의 각 활동을 1개의 노드(원 또는 사각형)로 표시하고 선행관계의 활동(화살표)으로 표시되는 AON(Activity On Node) 네트워크와 프로젝트 각 활동 1개의 화살표로, 활동 시작 시점이나 완료 시점을 이벤트로 정의하고 이를 노드로 표시하는 AOA(Activity On Arc) 네트워크가 있다.
 
AON 네트워크는 후술하는 가상활동이 필요가 없어 AOA 네트워크에 비하여 작성하기가 쉽지만, 프로젝트 활동만을 나타낼 수가 있고 활동의 시작/완료 시점을 나타내는 단계는 표시할 수 없어서 이벤트에 대한 정보를 알 수 없다는 단점이 있다. 그래서 무엇이 좋고 나쁘고를 떠나서 모든 네트워크를 사용하고 이해할 수 있어야 한다. 
 
PERT/CMP의 목적은 다시 말해 프로젝트의 일정계획과 통제가 주이다. 그러므로 프로젝트에서 수행되어야 할 자원과 시간을 소모하는 개별작업인 액티비티, 활동이 중요하다. 이 활동은 항상 시작 시점을 나타내는 시작노드와 완료 시점을 나타내는 완료 노드를 1개씩 갖는다. 여기서 더미 노드는 자원과 시간을 소모하지 않는 활동이 있으며 이는 활동 상호 간 전후 관계를 표시하기 위해 사용한다.
 
노드는 각 활동의 시작/완료 시점을 나타내며 활동과 활동을 연결하는 시점이며 시간이나 자원의 소비가 없는 순간적 시점이다. 그래서 활동과 활동은 항시 노드에 의해 연결된다. 또한 노드는 활동에 따라 분기 또는 결합이 되기도 하며 이에 따라 분기 마디/결합 마디라고 정의된다. 
 
프로젝트의 활동은 프로젝트 일정계획에 따라 정해진 순서대로 진행된다. 따라서 활동의 진행 순서와 활동 간 전후 관계를 네트워크 형태로 표시하면 프로젝트 전체 내용을 쉽게 파악할 수 있다. 이를 통해 각 활동 완료에 필요한 소요 시간을 추정하고 활동 간의 전후 관계와 활동의 진행순서를 나타낸 프로젝트 네트워크가 작성되면 추정된 각 활동의 소요 시간을 기준으로 각 활동의 일정을 계산할 수 있다. 여기서 우리가 흔히 접하는 도표가 갠트(Gantt)차트인데 사실 PERT/CPM이 개발되기 이전부터 많이 사용되어 오던 것으로 상호 간의 긴밀한 관계가 있으며 주 용도는 갠트차트는 프로젝트의 특정 부분의 활동 진척도를 파악할 때, PERT/CPM은 일정을 계산하는 데 사용된다.
 




 

프로젝트 네트워크 Critical Path

PERT/CPM 프로젝트 네트워크에서 출발 노드와 도착 노드를 잇는 활동들의 집합을 경로라고 하며 이 경로 중 가장 긴 경로를 주경로, Critical Path라고 한다. 그래서 주 경로상의 활동은 모두 여유시간이 없어서 이 활동 중 한 활동이라도 예정보다 지체된다면 전체 프로젝트의 완료 기간은 지연되게 된다. 따라서 이런 활동들은 매우 중요하게 중점 관리되는 대상이 된다.
 
이러한 주경로를 분석할 때는 모든 활동의 소요 시간이 변하지 않고 일정하다는 가정하에서 완전 열거법, 그리고 매우 복잡한 프로젝트에서 완전 열거법에 의해 주경로를 파악하기 어려운 경우에 사용하는 노드 시간 분석법을 사용한다. 그래서 대부분 규모가 있는 프로젝트에선 노드 시간 분석을 많이 쓰며 이를 통해 알 수 있는 것들은 주경로와 전체 프로젝트의 완료 기간 및 주 활동, 활동별 시작/완료 시간, 그리고 비 주 활동의 여유시간 등을 파악할 수 있다.
 
이에 주경로와 노드의 여유시간을 산출하고 노드 중심의 프로젝트 네트워크를 작성한다. 이를 통해 프로젝트 전반적인 진척도를 알 수 있어서 경영층에게는 활용도가 매우 높지만, 시작/완료 시점을 세세하게 파악하기는 어렵다. 그래서 실무자 관점에서의 개별 활동을 중심으로 주경로와 여유시간을 활동 시간 분석을 통해 구하는데 여기에는 주경로가 모든 경로 중 소요 시간이 가장 긴 경로라는 사실로 산출할 수 있는 정수 계획모형과 주경로가 여유시간이 없는 활동들로 구성된 경로라는 사실로 산출할 수 있는 선형계획모형이 있다.
 
이렇듯 프로젝트 활동 추적을 위해선 수학적 모형들이 사용된다. 다만 이 모형들은 과거 경험에서 얻는 변동 없는 확정적 시간을 데이터화할 수 있으며 이를 토대로 추정 방법을 사용하기도 하며 또는 활동 소요 시간을 확률분포 화하여 여러 값으로 추정하는 방법을 사용하기도 한다. 이러한 방법들을 바탕으로 프로젝트의 완료 기간을 단축할 수 있는 아이디어와 방법을 도출하여 실제 프로젝트에 적용, 관리하는 것 또한 매우 중요한 사안 중 하나이다.
 
 

 

 
※ 엑셀 사용해보기
PERT/CPM을 제대로 아는 것과 실제 사용해 보는 것은 완전히 다른 문제일 수 있다. 왜냐면 이를 현업에서 마주할 기회도 적을뿐더러(?) 학습해볼 상황도 거의 없다 봐도 무방하다. 단순히 학문적 경험과 시험을 위해 치르는 경험은 극히 일부분이며 내 손으로 구해볼 수 있는 상황 또한 전무하다. 그나마 관련한 여러 프로젝트 도구들이 있으나 이를 사용해 보는 일조차 쉽지는 않다. 그래서 그 대안으로 엑셀을 많이 쓴다. 원리를 알고 엑셀에서 필요한 값들을 제대로 매칭할 수만 있다면 프로젝트 관리역량은 매우 좋아질 것이다. 그러니 엑셀 자료들을 많이 활용해 보자. 요즘은 AI도 한 몫하고 있지 않은가?

소프트웨어 규모 산정 – 기능점수 (프로젝트 성공률 1% 높이기)

소프트웨어 규모 산정

컴퓨터를 기반한 시스템을 구축하면서 가장 비용이 많이 든 요소는 다름이 아니라 소프트웨어이다. 그래서 소프트웨어의 규모를 알아내는 일이 매우 중요하며 그 역사도 매우 깊다. 이러한 소프트웨어 비용은 사람, 기술, 환경 및 이를 둘러싼 정치, 정책이란 여러 변수의 영향을 많이 받는다. 
 
그래서 소프트웨어 비용의 신뢰성을 높이고 그 노력을 추정하기 위해 많은 방법이 있었다. 프로젝트가 끝날 때까지 추정을 미뤄보기도 하고 소프트웨어 공학을 활용하여 활동들을 분해하여 분석하기도 했으며 과거의 경험과 데이터를 바탕으로 추정하고 도구를 사용하기도 했다.
 
특히 개발 프로젝트의 대상인 소프트웨어의 범위를 양적인 크기와 질적인 수준으로 측정하여 규모를 파악함으로써 소요 공수, 투입자원 및 소요 기간을 파악하여 실행할 수 있는 계획을 수립하기 위해 규모를 산정한다. 이를 통해 투입인력 개개인의 생산성을 측정할 수 있으며 원가를 파악하여 비가시적인 소프트웨어 개발에 대한 최소한의 재무적 성과를 구축할 수 있다. 또한 조직의 실효성 있는 경영계획과 정책 수립에 크게 이바지를 할 수 있다.
 
앞선 글에서도 언급했었지만 소프트웨어 규모를 산정하는 방법은 다양하다. 양적 규모를 산정하는 방법에는 LOC(Line Of Code) 방식, Putnam(생명주기 예측) 모델 및 CoCoMo(Constructive Cost Model) 등이 있고 질적 규모를 산정하는 방법에는 Function Point, McCabe 회전 복잡도, Halstead 소프트웨어과학 등이 있다. 과거에는 소프트웨어도 단순하고 규모가 크지 않아 양적 규모 산정 방법만으로도 충분했으나 근래에는 소프트웨어의 복잡도도 증가하고 그 규모도 너무나 커져서 질적 규모 산정 방법으로 접근하며 그중에서 Fuction Point를 많이 사용하는 추세이다.
 
 

기능점수방식(Function Point)

Fuction Point는 사용자 관점에서의 소프트웨어 개발 규모를 측정하기 위한 표준 ISO/IEC 14143(FSM: Functional Size Measurement)기법으로서 사용자가 요구하여 받는 기능들을 측정하고 구현 기술과 무관하게 소프트웨어 개발 및 유지보수의 규모를 산정할 수 있다. 여기서 기능점수란 사용자 관점에서의 측정된 소프트웨어 기능의 양을 말하며 소프트웨어 기능은 논리적 의미에 따라 데이터와 트랜잭션으로 크게 나눠 볼 수 있다.
 
기능점수방식에서도 크게 일반적인 기능점수 산정 방법(정통 법)과 평균 복잡도를 적용하는 방법(간이 법)의 두 가지가 있으며 정통 법은 소프트웨어 기능을 도출, 각 기능의 유형별 복잡도를 고려하는 일반적인 방법으로 소프트웨어 개발 설계공정 후에 보통 사용되며, 간이 법은 기능의 복잡도를 판단하기 어려운 경우에 적용하며 계산 절차는 정통법과 동일하나 기능점수를 기능 유형별 평균 복잡도를 적용하여 산출한다. 이는 보통 기획 및 발주단계에서 사용된다.

 

비용과 노력 추정 매트릭스

< 비용과 노력 추정 매트릭스 >

기능점수방식은 기능을 중심으로 하는 소프트웨어와 개발과정에 대한 간접척도를 다루며 프로젝트 완료 후 생산성 평가목적으로 개발되었으나 사전 예측 모델로도 이용되고 있다. 이를 좀 더 살펴보면 생산성은 FP/노력으로 볼 수 있으며 품질은 오류 발생률(오류 수/FP)로 측정할 수 있다. 결함 수를 FP로 나누면 결함 발생률이며 비용효율성(=비용/FP) 및 문서화를 위한 측정도 가능하다.
 
이런 기능점수방식은 프로그래밍 언어와 독립적이어서 환경에 영향을 받지 않는 큰 장점이 있다. 하지만 보다시피 이를 잘 활용하기 위해서 숙련된 기술이 필요하고 주관적인 자료들도 많고 수집도 어려운 점이 있다. 특히 사용자 관점에서 이뤄지다 보니 감춰진 측정항목들이 있으며 사용되고 있는 파일 수를 정확히 파악하기가 어렵다.
 
아래는 기능점수에서 사용하는 5가지 측정 항목이다.
 

기능점수 5가지 측정 항목

 
EI(External Input)는 외부 입력측정(사용자 입력 개수), EO(External Output)는 외부 출력측정(사용자 출력 개수), EQ(External inQuery)는 외부 조회측정(사용자 질의 개수)이다. ILF(Internal Logical File)은 내부파일 개수, EIF(External Interface File)는 외부 인터페이스 개수이다.
 




계산 방법

🚩 단계1 : FP 테이블에 따른 기능 수 계산
기능유형                      Count  |  단순  |  보통  |  복잡  |  기능수(FC)
외부 입력:                       [ ]*        3         4         6         = [  ]
외부 출력:                       [ ]*        4         5         7         = [  ]
외부 조회:                       [ ]*        3         4         6         = [  ]
내부 논리파일:                 [ ]*        7        10       15         = [  ]
외부 인터페이스 파일:       [ ]*        5          7       10         = [  ]
 
🚩 단계2 : 복잡도 조정값 계산
14개 기술적 복잡도 요소에 영향도(0 ~ 5의 정수 표시)를 평가하여 합산하여 계산한다. 총영향도(0~70)는 항목(14개)에 영향도(0~5)를 곱하며 기술적 복잡도(TCF)는 0.65 +0.01 * 총영향도로 나타낼 수 있다. 여기서 14개 요소에는 통신, 분산처리, 시스템성능, 사용 빈도, 트랜잭션 비율, 온라인 요구, 온라인복잡도, 파일갱신, 재사용성, 처리 복잡성, 유지보수성, 회복성, 이식성, 분산성이 있다.
 
🚩 단계3 : FP 계산
기능점수(FP)를 계산하며 FC (기능 수)에 TCF (기술적 복잡도)를 곱한다.
 
🚩 단계4 : 경험 데이터 이용 프로젝트 비용과 개발 노력 추정
전체적인 프로젝트 비용은 FP에 FP 당 비용(경험치)을 곱하며, 개발 노력은 FP를 생산성(경험치)으로 나눠 측정한다.
 
 
 
 
※ 직접 해봐야 안다.
쉽지는 않다. 과거의 유사 사례 경험, 양식들이 있다면 우선은 먼저 자료를 구해서 진행하고 있는 프로젝트에 적용해 보길 바란다. 쉬운 방식으로 몇 번 하다 보면 얼추 감이 온다. 그러면서 다른 산정 방법도 같이 하여 서로 값을 비교해보는 것도 좋다. 자주 해보고 나만의 경험을 쌓고 데이터를 쌓아가면서 공부를 해봐야 한다.

내부 제안서 (프로젝트 성공률 1% 높이기)

제안서. 내부? 외부?

기업에서 진행하는 제안서의 대부분은 외부 고객을 위하여 작성한다. 하지만 외부 고객 못지않게 중요한 것이 내부 고객이다. 하지만 그 중요성을 인식하면서도 제대로 된 제안하는 경우가 드물다. 물론 하지 않는 것은 아니지만 외부 고객에게 하는 만큼 신경을 덜 쓰는 경우가 많다. 하지만 내부 고객이 기본적으로 만족해야 대외적인 성과도 거둘 수가 있다. 
 
제안, 프로젝트 계획은 기업의 필수적인 경영 수단이다. 기업의 첫 시작뿐만 아니라 이미 운영이 되는 기업 조직에도 더욱 절실하다. 잘 작성된 내부 제안서는 경영진뿐만 아니라 실무부서에서도 중요하다. 이에 굳이 대내외 제안서를 구분해 본다면 어떤 면들이 있는지 살펴봐야 한다.
 
 

내부 제안서의 특징들

✅ 전략 방향
: 모든 제안이 그러하듯 가장 중요한 것은 방향성이다. 고객의 니즈가 파악되었다면 어떻게 문제를 풀어갈지, 이 해결책이 궁극적으로 지향하는 목표가 어디인지를 먼저 결정해야 한다. 그렇기 때문에 모든 방향을 염두에 두지만 필요하다. 이러한 결정에는 수많은 계획과 토론, 분석 등을 통해 오너십을 가진 당사자는 전략적 통찰력을 가져야 한다. 이는 저절로 얻어지는 것이 아니라 계획의 첫 단추를 꾀고 효과적인 이행을 위한 의도를 가지고 현실에 접근해야 한다. 모든 것에 주의를 기울이되 빠른 판단과 과감한 행동을 요구한다.
 
✅ 성과
: 제안은 성과를 거둬야 한다. 설득을 통해 가져갈 수 있는 조직을 위한 구체적 성과는 단순한 열매 이상의 과정이 필요하며 이를 통해 모든 구성원이 한 목표를 향해 나아갈 수 있도록 하며 개인과 조직의 성과를 연계하여 기업의 목표를 달성하도록 도와준다. 성과는 피상적이어서는 안 되며 매우 구체적이고 실현할 수 있는 기간 설정과 명확한 목표치를 가져야 한다. 이를 통해 우선순위를 결정하고 프로젝트 기간 내에 맞춰 움직일 수 있도록 조율한다.
 
✅ 성과 측정
: 모든 성과는 지표로 정량화되며 이 지표들은 반드시 명확하고 측정할 수 있는 목표를 제시해야 한다. 다시 말해 목표를 수립하고자 할 때 중요하게 몇 가지는 구체적이어야 하며 측정할 수 있어야 하고 이해당사자들의 합의가 이루어진 현실적이면서 실행 시기가 정해져야 한다. 원대한 목표 뒤에는 뚜렷한 성과를 뒷받침을 달성 방법도 개발하고 이해하여야 한다. 성과 측정은 이에 대한 근간이다.
 
✅ 협력
: 내부여서 장점도 있지만 오히려 이 장점이 프로젝트 진행을 더디게 할 수 있다. 여기서 공과 사는 명확히 발라내야 한다. 성과목표가 설정되고 이를 수행할 조직과 기간이 정해지면 동일한 목표를 위한 이해당사자들의 간의 협력이 매우 중요하다. 여기서 각 조직의 목표를 명확히 하고 구두가 아닌 문서로 공식적 의사소통 경로를 통해 세밀한 통제를 해야 한다. 그렇지 않으면 모든 관계가 동네 사랑방으로 전락하는 수가 있다.
 
✅ 의사소통
: 내부 프로젝트 또한 외부와 마찬가지로 의사소통이 매우 중요하다. 이 정점에는 경영진이 있어야 하며 그들의 의지를 기반으로 하여 공유하고 결정을 내려야 한다. 수면 아래 모든 이슈를 끌어올려 의제화해야 하며 이때 상하관계는 중요하지 않다. 지위에 따른 특권은 철저히 배제하고 프로젝트 관리자 중심으로 모든 것이 통제되고 관리되어야 한다. 특히 실무진의 참여가 필수이며 이들의 목소리를 들어야 한다. 내부 프로젝트는 공유야말로 프로젝트의 성패를 좌지우지한다.
 
✅ 임파워먼트
: 제대로 된 의사소통의 이면에는 원활한 권함 위임이 자리한다. 여기까지 된다면 내부적인 강력한 동기부여는 어떠한 프로젝트이던 성공적으로 마무리할 수 있는 가능성이 커진다. 모든 구성원이 자신의 업무로 프로젝트를 받아들이고 적극적으로 참여하며 자신감을 갖게 되는 비결이 여기에 있다. 신뢰와 믿음은 어떠한 위험도 긍정적으로 해소할 수 있는 힘을 갖게 한다. 자발적 움직임은 기대하지 않았던 곳에서 나온다.
 




 

계획과 실천

제안서가 작성된다. 여러 난관을 뚫고 하나둘 내용이 채워지는 가운데 여러 이슈가 도출된다. 특히 예산 부분은 내부 프로젝트라는 특성 때문에 여러 측면에서 불합리한 판단과 결정이 내려질 수 있다. 예산이 매우 중요하지만, 내부 자원을 투입하는 입장에서 평가를 내세워 제대로 된 계획이나 기준, 배분 등에 문제가 발생할 수 있다. 특히 인건비의 경우가 그렇다. 최악의 경우 내부 인력의 인건비는 급여로 대체되고 시장에서 평가받는 단가를 무시되어 버린다. 이 지점에 경영자와 직원 사이의 입장이 충돌할 수 있다. 
 
무엇보다도 수명업무를 가진 상태에서 프로젝트가 부가적인 업무로 추가가 될 때 프로젝트 구성원들의 불만은 최고조에 달한다. 평상시 100의 일을 하고 있는데 여기에 50이 더해지지만, 시간은 그대로인 경우가 많다. 정해진 업무시간에 모든 것을 하라고 하는 것은 대부분 내부 프로젝트를 병들게 하고 실패 확률을 높이는 가장 큰 원인이 된다.
 
예산의 그 편성과 계획을 분리하여야 한다. 계획은 최우선으로 주기별 예산을 수립해야 한다. 기업의 자금흐름을 바탕으로 투자와 비용지출을 구분한다. 전략을 바탕으로 계획 과정부터 전략 달성의 가능성을 테스트하고 모든 수단을 강구해야 한다. 예상 재무 효과를 평가하고 경영진의 판단과 참여를 적극적으로 유도하여야 한다. 그들이 설득될 수 있는 명분을 제시하고 행동해야 한다. 제안서는 문서에서 벗어나 행동력을 발휘해야 한다. 계획이 문자로만 존재하면 아무 일도 일어나지 않는다. 앞선 중요 요인 중 무엇 하나 빠지지 않게 관리하고 운영해야 한다.
 
내부 프로젝트라고 구성원들에 대한 헌신을 강요해서는 안 된다. 목표, 행동, 시기를 실시간으로 수정할 수 있어야 하며 소통하고 참여시켜야 한다. 쓸데없는 주인의식을 강요하지 말고 동의를 구하고 납득시키며 함께 나아갈 수 있는 길을 열어줘야 한다. 경영진의 관심이 사그라지지 않도록, 색안경을 끼고 보지 않도록, 잘못된 판단과 결정이 내려지지 않도록 항상 날을 세워야 한다. 그래서 내부 프로젝트가 외부 프로젝트보다 더 어려운지도 모르겠다. 
 
 
 
 
※ 과연? 과연!
내부 프로젝트가 제대로 끝난 경우를 나를 포함해서 주변에서도 잘 보지 못한 것 같다. 호기롭게 시작된 일들은 종단에 가선 흐지부지되는 경우도 많다. 어떤 경우엔 서로 상처만 가득 안고 헤어지는 경우도 많이 본 것 같다. 이미 잡아놓은 물고기여서 그런 것인가? 어디서 감히 이런걸? 이라는 생각들이 지배적인가? 눈에도 보이는 수많은 장벽을 깨지 못해서 그런가? 장을 만들어 줬다는 것만으로 내 일은 다했는 것인가? 몸과 마음이 피곤해도 오히려 밖에 나가서 일하는 것이 더 좋다고, 꼴보기 싫은 상황을 피하고픈 웃기지도 않는 상황들은 너무도 많다. 그러나 이 모든 것을 차치하고 내부 프로젝트가 망하는 가장 큰 몫은 경영진에게 있다고 감히 말해 본다. 그것이 편하다. 그리고 정말 맞다.

제안서(2) (프로젝트 성공률 1% 높이기)

제안서 프로세스

지난번 내용 중 제안서를 위한 일반적인 프로세스 6단계에 대해서 대략 정리하였는데 이를 좀 더 자세히 알아보자. 우선 제안서는 설득의 글이다. 다시 말해 단편적 지식의 나열이나 하나에 집중하기보다는 전체적인 맥락을 이해하고 하나의 이미지로 접근해야 한다. 그 중심엔 고객이 있다. 고객이 결정되고 나면 그 고객의 모든 것에 대해 알아야 한다. 
 
모든 것을 알기 위해선 먼저 기준이 필요하다. 그 기준의 부합 여부에 따라 전략, 전술이 달라진다. 기준은 가설에 따라 설정된다. 가설을 세우고 가설을 검증하는 과정을 반복하면서 우리는 고객에 좀 더 가깝게 접근할 수 있다. 물론 준비된 고객들도 있지만 대부분은 강한 니즈와 문제의식을 가지고 있으면서도 그래서 무엇을 하고 싶은지를 명확히 표현하지 못하는 경우가 많다. 
 
이 부분은 문제에 대해서는 잘 알지만, 문제점, 즉 원인을 파악하지 못하는 경우다. 문제와 문제점은 다르다. 가설을 세우고 검증하는 과정은 문제에서 문제점으로 접근하는 최단의 경로이다. 이를 통해 고객은 문제점을 인식하고 제대로 원하는 것이 무엇인지 표현할 수 있다. 제안서는 이를 도와주는 설득의 도구이다.
 
 

1️⃣ 정보 수집, 분석 및 가설 설정

가설을 세울 때 필요한 것이 무엇인가? 그것은 정보이다. 많은 정보를 획득할수록 제대된 가설 또한 수립할 수 있다. 물론 고객에 대한 정보가 아주 완벽하게 수집되었다 해도 이런 정보들을 친절히 알려주고 가르쳐 주는 고객은 거의 없다. 따라서 한정된 정보 속에서 우리는 실마리를 찾아내야 하는 것이다.
 
여기서 제대로 된 가설은 없을 수 있다. 가설이 맞고 틀리고가 아니고 당연히 잘못되어 있을 수도 있다. 하지만 가설을 통해 고객이 정말 중요하게 생각하는 점을 그려보는 것이 진짜 중요한 일이다. 가설이 없다면 중구난방 횡설수설할 수 있으며 정보의 중요도도 알아내지 못할 수 있다. 요구사항 아래 잠재적 요구사항을 끄집어내는 일 또한 우리의 일이다.
 
정보는 관점이 중요하다. 수집하되 하나의 단면만 보면 안 된다. 즉 고객, 경쟁사, 고객의 고객 및 거래처의 관점이 필요하다. 이를 통해 제대로 된 요구사항을 확인해 볼 수 있다. 또한 정보는 숨어있는 부분도 많다. 그래서 일반적인 정보와 더불어 고객에게서 입수해야 할 정보도 꼼꼼하게 챙겨야 한다.
 
수집, 획득된 정보는 면밀한 분석이 필요하다. 그와 동시에 가설을 준비한다. 가설은 정보수집의 관점들을 토대로 고객의 장단점 및 기회와 위기를 참작한다. 또한 제약조건은 두지 않고 고객의 눈높이 맞춰 설정해야 한다. 가설은 검증(사실임을 증명할 가능성, 거짓임을 증명할 가능성, 결과에 대해서는 재현 가능성)할 수 있어야 하며 더 간단하거나 정확한 방법을 설명할 수 있다면 다시 설정해야 한다.
 
 

2️⃣ 요구사항 정리

요구사항 정리는 가설의 정리라고도 할 수 있으며 일종의 사전 제안서 형태로 할 수 있다. 여기에는 설정한 가설을 구체적으로 기술하고 고객 요구사항과의 일치성, 또한 어느 부분이 잘못되었는가를 확인하고자 함이다. 이를 통해 수집된 정보를 제대로 분석했고 이해했는지, 잠재적 요구사항들이 도출되었는지도 가려낼 수 있다.
 
이러한 사전 제안서는 가설검증의 도구라고 보면 된다. 그렇기 때문에 세밀하고 구체적인 내용으로 정리해야 한다. 명확하지 않으면 안 된다. 그래서 정성적인 부분도 정량화하는 노력이 필요하다. 또한 하나의 사실에 대한 주변 인터페이스를 살펴야 한다. 누구에 의해서, 누가 작성했고 어디에 쓰이는지, 그 결과는 무엇인지를 명확히 알아야 한다. 정보의 객관화가 여기서 필요하다. 정보의 논리 근거가 필요하다.
 
 

3️⃣ 인터뷰 및 가설 검증

준비된 자료를 바탕으로 가설이 맞는지 검증하는 단계이다. 이때 주된 방법은 인터뷰이다. 다만 목적을 명확하게 하는 인터뷰를 준비하여야 한다. 경청을 기본으로 알고 싶은 내용을 관계자에게 질의응답 방식을 통해 정보를 확인하고 알아내기 위함이다.
 
우리가 대화 속에서 정보를 획득하는 것이 쉬워 보일 수도 있지만 이는 대단히 어려운 일 중 하나다. 그래서 관련한 여러 기술들을 참고해 볼 수도 있는데 그래서 많은 경험 또한 필요한 부분이다. 특히 인터뷰의 목적을 명확히 하는 것은 여러 인터뷰 방식 중 우리는 정보수집을 위한 인터뷰를 하려 하기 때문이다. 이를 중심으로 설득 또한 같이 진행하게 된다.
 
인터뷰는 인터뷰 대상자를 선별한다. 대상자가 누구냐에 따라 그 결과는 천차만별이다. 그러므로 아무나 대상자로 하면 시간과 비용만 낭비된다. 실무자인지 관리자인지 혹은 경영자층인지에 따라 정보의 양과 질이 다르다. 그래서 수집된 정보의 분석이 필요한 것이다. 대상자가 선별되었다면 질문을 준비해야 한다. 질문의 목적을 통해 다양하게 준비하고 리스트를 만들어 관리한다. 
 




 

4️⃣ 결과정리

인터뷰가 진행된다. 앞서 언급했듯이 그 목적이 중요한 만큼 인터뷰 대상자에게 목적을 알리고 최대한 협조할 수 있는 분위기를 조성한다. 이 부분은 의사소통의 스킬을 기반으로 대상자에게 어떠한 부분에 관심이 있는지, 그들의 입장이 무엇인지, 그리고 대답하기 곤란하지 않은지 면밀히 살펴야 한다.
 
인터뷰가 끝나면 그 내용을 제안에 반영하기 위해 가설을 검증하고 수정을 진행한다. 만약 가설이 고객의 요구사항과 일치하면 상관이 없지만 그렇지 않다면 계속 반복, 피드백하여야 한다. 그러기 위해선 인터뷰 내용을 잘 정리한다. 별도 회의록을 만들어 작성하고 필요시 녹취 등을 통해 정보의 유실을 막는다. 
 
인터뷰 내용을 기술할 때 가장 중요한 점은 인터뷰에 참석하지 않은 인력이 그 내용을 보더라도 당시의 내용은 물론 상황까지도 알 수 있도록 쉽게 써야 하는 것이다. 그러기 때문에 답변의 뉘앙스까지도 잡아내야 한다. 그러한 미묘한 차이점이 중요한 의미를 지니고 궁극엔 결과도 다르게 나타날 수 있기 때문이다.
 
정리된 회의록을 통해 가설 검증을 수행하고 문제가 있다면 수정작업을 진행한다. 이는 why, what, where를 명확히 하는 작업이다. why와 what이 명확해질 때까지 계속 확인을 하며 이를 통해 제안범위가 최종적으로 확정된다. 이 세 부분이 스스로 납득이 간다면 이제 최종적인 제안서 작성에 들어갈 준비가 된 것이다.
 
 

5️⃣ 제안서 작성

제안서는 템플릿이 많다. 하지만 고객사가 제공하는 경우도 있을 수 있기 때문에 큰 제약이 되지는 않는다. 형식도 중요하지만, 내용이 더 중요하기 때문이다. 그래서 작성에 많은 신경을 써야 한다. 다른 것도 마찬가지지만 제안의 제목은 확정이 되었기 때문에 제일 어려운 장애물은 제거되었다.
 
그다음 할 일은 목차를 작성하는 것이다. 사실 제목과 목차가 전부이다. 대부분은 제안서에서 제목과 목차가 차지하는 비중은 80%이다. 나머진 사전 제안서를 바탕으로 내용을 채워 넣는 일이기 때문이다. 목차를 통해 스토리를 구성하고 조립한다. 소설처럼 극적인 장치도 마련할 수 있다. 이런 부분은 물론 충분한 논의와 사유가 있어야 하지만 목차 구성만으로도 우린 상대를 설득할 수 있어야 한다.
 
제안서는 그 범위와 경중 등에 따라 혼자 쓸 수도 있고 팀으로 작성할 수도 있다. 최대한 간결한 표현으로 간단하게 이해할 수 있도록 작성해야 한다. 오해가 없어야 하며 사실에 근거하여 기술한다. 여기서 금물은 많이 써봐서 혹은 잘 쓰기 때문이라는 과신이나 선입견이다. 그래서 다양한 관점의 검토가 필요하다. 작성된 제안서는 반드시 객관적 입장에서 평가를 할 수 있는 사람에게 검토받아야 한다.
 
 

6️⃣ 발표

큰일이 모두 끝났다. 하지만 대미를 장식할 더 큰 일, 발표가 있다. 제안은 발표로 완결된다. 제아무리 훌륭하게 작성된 제안서도 어떻게 발표하느냐에 따라 그 결과는 달라진다. 다르게 이야기하면 미흡한 제안서라 할지라도 훌륭한 발표를 통해 제안 기회의 불씨를 살릴 수도 있다는 것이다. 
 
이렇게 중요한 발표는 제안서를 완전히 체화한 발표자를 중심으로 열의와 의욕을 불태워야 한다. 당연히 기술력을 기반으로 고객에게 신뢰를 주어야 하며 요구사항을 제대로 충족시켜 주어야 한다. 고객의 혼란을 야기할 정보들은 정리가 되어야 하며 누구에게 제안하는지, 왜 무엇을 하는지를 확실히 하고 넘어간다. 이를 통해 작성된 스토리에 고객이 동감하고 감동하며 진실한 태도에 고개를 끄덕일 수 있다.
 
 
 
 
※ 무늬만 대표자? 
정말 힘들게 작성한 제안서를 들고 가서 보기 좋게 말아먹는(?) 발표자가 있다. 이는 제안에 참여한 모든 이들을 배신하는 것이다. 그런데 그것을 잘 모르는 발표자가 많다. 대부분은 아니지만, 발표자라면 제안서를 완전히 씹어 먹고 내 것으로 만들지 못한다면 절대 발표하면 안 된다. 왜냐면 발표하면서 내가 얼마나 이 제안에 진심인지가 낱낱이 드러나기 때문이다. 고객도 당연하지만 발표하는 자기가 가장 잘 안다. 발표자 자신이 직급이 있다고, 대표성이 있다고 자신할 것도 아니다. 혼자 잘난 체할 것도 아니다. 남이 다 차려놓은 밥상에 숟가락을 올리지 말고 그 밥상 차림에 일조하길 바란다. 이 자리를 위해 고생하고 애쓴 사람들을 봐서라도..

제안서 (1) (프로젝트 성공률 1% 높이기)

제안서?

개발자라는 직업은 많은 능력과 역할이 필요하다. 이는 단순하게 개발에만 국한되어 있지 않다. 모든 것이 개발이지만 개발자가 생각하는 개발은 보통 코딩 또는 프로그래밍만을 생각한다. 하지만 개발이라는 수명주기를 놓고 본다면 프로그래밍은 전체에서 약 20% 정도밖에 차지하지 않는다. 나머지는 기획, 관리, 의사소통, 문서 등 프로젝트 전반의 모든 구성 요소들이 차지한다.
 
‘저는 개발만 하렵니다.’라고 생각한다면 그 넓은 운동장에서 구석 한 귀퉁이에 앉아 모래 장난을 하는 것과 다르지 않다. 특히나 문서로 의사소통하는 프로젝트에서 그 시작 지점의 제안은 누군가가 만들어 주는 것이 아니다. 개발자에게 계속 요구되는 능력 중의 하나로 IT에 관련한 모든 기업, 조직과 인력들에 주어진 과제이다.
 
고객에게 구두로만 내용을 전달할 수는 없다. 결국 손에 문서를 쥐여주어야 하고 그 내용을 그대로 만드는 제안서는 어떠한 방법을 써서라도 부가가치를 높이면서 고객에게 제안한 모든 가치를 인정받을 수 있게끔 작성이 되어야 한다. 그래서 준비 여하를 막론하고 이 과정에서 수많은 시행착오를 거치기 마련이다.
 
제안서는 누가 써주지 않는다. 그 기저에는 개발자가 있다. 그리고 그 개발자가 경력이 쌓이고 시간을 누적하면서 제안개발의 능력을 키우게 된다. 나 자신뿐만 아니라 고객에게 눈을 맞출 수 있으며 고객의 문제에 한 발짝 더 가까이 다가가고 모든 기회를 확대하면 제안에 성공할 수 있다.
 
 

변화무쌍한 제안서

제안은 영업활동이다. 영업은? 개발이 아니다. 그래서 개발자들은 대다수 제안을 남의 일이라고 생각한다. 사업 초기 영업맨들이 열심히 과제를 따와서 제안서를 쓰고 모든 것이 다 된 이후 전달이 되면 그때부터 내가 하는 일이 아니다. 물론 제안과 개발을 분담하는 것이 자연스럽다고 볼 수 있으나 시스템을 만드는 입장에서는 제안은 개발이다.
 
개발자가 제안하고자 한다면, 그 기저에는 다음과 같은 자세와 능력이 필요하다.
 
✔️ 충분한 기술력: 문제 해결력이다. 
✔️ 의사소통 능력: 고객의 요구사항을 제대로 확인할 수 있어야 한다.
✔️ 고객의 문제를 객관화: 명확하고 구체적인 사실에 입각한다.
✔️ 적극적 해결책 모색: 관망이 아니라 수행이다.
✔️ 고객 만족과 매출 확보: 이익 창출
 
즉, 풍부한 IT 지식과 경험을 토대로 한 다양한 문제 접근과 해결책을 강구하고 이에 따른 고객의 요구사항을 만족시킬 수 있는 능력은 개발자만이 할 수 있다. 그래서 단순하게 돌아다니는 템플릿을 하나 가져다 베끼듯 제안서를 만드는 것이 답일 수는 없다. 목적을 달성하기 위한 제안서는 체계적인 프로세스가 있고 도구들이 있다. 
 
또한 제안서는 의사소통의 결과이다. 의사소통을 원활히 하기 위해서 정보를 획득하여 분석하고 목표를 위한 동기를 부여하며 여기에 기반을 둔 최적의 실현 방법을 통한 설득에 있다. 원활한 의사소통은 고객과의 약속을 문서화하며 계약이 된다. 그럼 계약서에는 무엇을 담고 있어야 하는가? 무엇을 전달해야 하는가?
 
✔️ 배경, 현상, 이유: 왜 프로젝트를 하려 하는가?
✔️ 목적과 목표: 프로젝트의 성과는 무엇인가?
✔️ 제안 범위: 시스템화(견적 요건)의 대상은 무엇인가?
✔️ 수단과 방법: 어떻게 구현할 것인가?
✔️ 일정: 납기와 산출물은 무엇인가?
✔️ 체계: 프로젝트 추진은 어떻게 하는가?
✔️ 비용: 투자 판단의 근거는 명확한가?
 
위의 내용 중 가장 중요한 것은 무엇인가? Why와 What일 것이다. 이것이 명확해야지만 나머지 내용들이 의미를 갖는다. 고객이 처한 여러 현상과 문제들, 요구하는 배경과 프로젝트의 필요성, 그리고 문제들을 해소할 구체적인 프로젝트 성과들이 그것이다. 이 배경과 목적은 결국 비즈니스이다. 상호 간의 관계의 정확한 이해가 비즈니스를 알아내는 것이며 이후 제안의 본격적인 작업이 시작된다. 비즈니스를 이해하지 못하면 제안서는 오만가지 형태로 나온다. 이것도 답인 것 같고 저것도 답인 것 같다. 제안서가 달라지는 것은 그 원인을 파악하지 못함에 있다. 제안서는 절대 변화무쌍하지 않다.
 




 

제안서 프로세스

제안서를 위한 일반적인 프로세스는 보통 6단계로 되어 있다. (물론 발주처와 공급처의 입장에 따라 다를 수는 있겠지만 큰 틀에서는 하나의 동일한 흐름이다.)
 
1️⃣ 정보 수집, 분석 및 가설 설정: 고객 정보를 토대로 과제나 요구사항에 대한 가설 수립
2️⃣ 요구사항 정리: 요구사항 도출을 위한 초기 제안
3️⃣ 인터뷰 및 가설 검증: 경청과 검증, 전략회의
4️⃣ 결과정리: 수정과 반복, 확인, 제안팀 구성
5️⃣ 제안서 작성: 명확한 배경과 목적에 대한 해결책 구성, 제안 요약, 제안서
6️⃣ 발표: 고객 설득과 제안 목적 달성
 
앞서도 이야기했듯이 배경과 목적을 알아내기 위한 작업이 우선이 되고 제안서 작성은 그 이후의 일이다. 제안서 작성 전까지 1️⃣에서 4️⃣는 지속, 반복된다. 이를 통해 제안서를 성공시키기 위한 키를 확인한다. 그것은 가설이다. 고객 요구사항을 명확하게 끌어내는 일은 가설을 세우고 그 가설을 검증하는 것이다. 가설은 막연하게 흩어져 있는 여러 사안을 구체화하여 고객과 함께 잠재적인 요구사항까지 명확하게 도출하여 형태를 갖추면 된다. 흔히 고객이 가장 잘 알 것 같지만 의외로 고객 스스로 요구사항을 명확하게 정의하는 일은 드물다. 그래서 개발자가 컨설팅하며 가설을 만들어 검증하는 것이다. 혹 가설에 문제가 있다면 다시 만들면 된다.
 
 
 
 
※  제발 개발만 하게 해주세요!?
일하다 보면 다양한 사람들을 만나게 되는데 가끔 당황스러울 때가 있다. 특히나 신입도 아닌 경력 있는 ‘능력자’들이 자신의 주된 직무를 강조하며 오로지 그것만 할 수 있게 해달라는 것이다. ‘개발만!’, ‘영업만!’, ‘마케팅만!’. 이렇게 ‘무엇!’만을 할 수 있게 해달라고, 자신을 다른 일에 엮이지 않게 가만 놔두라는 요구가 과연 가능한지, 맞는 것인지 되물어 보지 않을 수 없게 한다. 이는 자신을 스스로 작은 방에 가두는 일이며 당장은 편하고 신경 쓸 일이 없겠지만 추후엔 아무것도 할 수 없음을 모르는 것일까? 그저 눈 앞의 뭔가를 회피하기 위한 것이라면 다시 생각해 볼 일이다. 회사 차원에도 매우 심각하게 받아들여지는 이런 태도들은 결국 개인과 회사 모두에게 득이 될 것은 전혀 없다. 전혀!

CMMI (2) (프로젝트 성공률 1% 높이기)

CMMI 구조

CMMI는 이행과 내재화를 통해 운영된다. 수립된 프로세스에 따라 업무를 수행하고 이를 통해 내재화가 된 업무는 불특정 다수의 사람이 와서 수행하더라도 똑같은 방식으로 업무는 수행된다. 이런 방식이 가능한 이유는 모델 구조에 기안한다. 모델은 크게 성숙단계(단계적 표현 방법) 혹은 능력단계(연속적 표현 방법), 프로세스 영역, 일반/특정 목적, 공통 수행항목 그리고 일반/특정 프랙티스로 나뉜다. 다음은 단계적 표현 방법이다.
 
 

단계적 표현 방법의 모델 컴포넌트< 단계적 표현 방법의 모델 컴포넌트 >

 
✔️ 성숙 단계(Maturity Levels)
: 조직에서 해당 업무를 얼마나 체계적으로 수행하고 있는지를 나타내는 지표로서 단계1이면 조직은 임기응변으로 업무 수행, 단계2이면 기본적인 프로젝트 관리 활동을 수행하고 있음을 말한다.
 
✔️ 프로세스 영역(Process Area)
: 해당 프로세스를 위해서 수행되어야 하는 활동들의 집합으로 하나의 프로세스 영역은 반드시 성숙단계 2, 3, 4, 5중 하나에 포함된다.
 
✔️ 목적과 프랙티스
: 모든 프로세스 영역은 달성해야 할 몇 가지 목적을 갖는다. 이러한 목적은 해당 프로세스 영역이 조직 내에서 수행되고 있음을 판단하는 기준이 되며 추상적으로 정의된다. 그래서 목적들은 보다 구체적으로 기술된 프랙티스들과 연결된다.
  – 특정 목적(Specific Goal): 특정 프로세스 영역과 관련된 목적
  – 일반 목적(Generic Goal): 모든 프로세스 영역에서 공통으로 적용될 수 있는 목적 (조직 내재화 판단)
  – 특정 프랙티스(Specific Practice): 특정 목적을 충족시키기 위해 조직이 수행해야 할 활동
  – 일반 프랙티스(Generic Practice): 프로세스가 효율적으로 지속될 수 있도록 해당 프로세스를 내재화하는 활동
 
✔️ 공통 수행항목(Common Features)
: 프로세스 영역 내에서 일반 프랙티스들이 그 특성에 따라 그룹화한 것 (단계적 표현 방법에서만 사용)
  – 수행방침(Commitment to Perform): 경영진 참여나 문서화 정책 관련 활동
  – 수행 능력(Ability to Perform): 프로세스 수행계획수립, 자원 제공, 교육 등과 관련한 활동
  – 직접 이행(Directing Implementation): 형상 관리, 관련 이해당사자의 식별, 참여, 프로세스 모니터링, 통제, 개선정보 수집 관련 활동
  – 이행검증(Verifying Implementation): 표준 준수 여부의 객관적 평가, 상위 관리자 검토 등 관련 활동
 
 
다음은 연속적 표현 방법이다. 이는 기본적으로 단계적 표현 방법과 동일하나 일반 프랙티스를 공통 수행항목으로 구분하지 않고 특정 프랙티스를 기본 프랙티스(특정 프랙티스 중 능력 단계1에 해당하는 프랙티스들)와 고급 프랙티스(특정 프랙티스 중에서 능력 단계2 이상 해당하는 프랙티스들)로 구분하는 것이 다르다.
 

연속적 표현 방법의 모델 컴포넌트< 연속적 표현 방법의 모델 컴포넌트 >

 
 
단계적 표현 방법(성숙 단계)은 조직 내 체계적 업무 수행의 정도로 1단계에서 5단계까지 구분한다. 그래서 계단처럼 구성되어 있으며 각 단계 프로세스 영역이 만족하여야 다음 단계로 넘어갈 수 있다. 이에 반해 연속적 표현 방법(능력 단계)은 프로세스 영역 능력 수준을 측정하는, 해당 조직의 프로세스 영역에 대한 능력 정도를 나타낸다. 이를 통해 영역별 수준을 확인해서 어떤 영역이 잘되는지 어떤 영역이 떨어지는지 확인할 수 있다.
 
 

CMMI 표현

앞선 구조처럼 조직의 프로세스 개선 활동의 우선순위가 CMMI에서 정의한 프로세스 영역들과 유사한 경우라면 단계적 표현 방법을 선택하면 훨씬 더 체계적일 수 있고 그렇지 않고 조금 특이한 경우라면 연속적 표현 방법을 적용하면 더 효율적일 수 있다. 이이 각 표현 방법들이 어떤 것인지 살펴본다.
 
🚩 단계적 표현 방법
:조직에서 프로세스 개선 활동을 수행할 때 하나의 로드맵을 제시하는 데 중점을 둔다. 이는 한 조직의 프로세스 능력이 발전되는 과정을 몇 가지 성숙 단계로 정의하고 상위 성숙 단계로 도달하기 위해서는 반드시 그 하위의 모든 성숙 단계들을 충족시켜야 한다.
 
✔️ 성숙 1단계: 초기(Initial)
  – 조직은 구조화된 프로세스가 없다. 모든 것이 임기응변적이다. 아무런 활동을 요구하지도 않는다.
 
✔️ 성숙 2단계: 관리됨(Managed)
  – 기본적인 프로젝트 관리 프로세스들이 있으며 그것에 따라 업무가 수행되고 있다. 기본적인 활동들이 있다.
 
✔️ 성숙 3단계: 정의됨(Defined)
  – 해당 조직에서 따라야 하는 조직 차원의 표준 프로세스가 있다. 훨씬 구체적이고 정교한 프로세스가 관리된다.
 
✔️ 성숙 4단계: 정량적으로 관리됨(Quantitatively Managed)
  – 모든 프로세스가 통계적이고 정량적이다. 의사결정이나 개선 여부 파악을 위해 메트릭을 활용한다.
 
✔️ 성숙 5단계: 최적화(Optimizing)
  – 프로세스 성과 변동 중 일반적인 원인에 대한 분석을 통해 지속 개선한다. 아주 이상적인 조직의 상태이다.
 
🚩 연속적 표현 방법
: 프로세스 영역들이 프로세스 관리, 프로젝트 관리, 엔지니어링, 지원의 4가지이다. 이는 개별 프로세스 영역 내에서의 프로세스 개선 활동에 초점을 두고 개별 프로세스 영역별로 능력 단계를 부여할 수 있기 때문이다.
 
✔️ 능력 0단계: 불완전함(Incomplete)
  – 요구되는 대부분의 활동이 수행되지 않는다. 
 
✔️ 능력 1단계:수행됨(Performed) 
  – 정의된 기본 프랙티스들이 기본적으로 수행되고 있다. 다만 확신할 수는 없다.
 
✔️ 능력 2단계: 관리됨(Managed)
  – 하나의 프로세스가 개별 프로젝트나 팀별로 계획, 수행, 추적 및 통제되고 있다. 이 단계부터 기본적 메트릭을 수집해야 한다.
 
✔️ 능력 3단계: 정의됨(Defined)
  – 표준 프로세스를 tailoring 가이드에 따라 조정하여 적합한 프로세스를 개발하고 활동을 관리한다.
 
✔️ 능력 4단계: 정량적으로 관리됨(Quantitatively Managed)
  – 정의된 프로세스가 통계적 기법이나 다른 정량적인 방법 등을 통해 관리되고 있다.
 
✔️ 능력 5단계: 최적화(Optimizing)
  – 하나의 프로세스를 반복 수행한 결과가 가지는 변동의 일반적 원인에 대해 분석, 개선하여 변동의 범위를 지속 줄여나간다.
 

CMMI 비교

이와 같이 두가지로 구분된 모델은 어떻게 비교가 될까? 각가의 특장점이 있어서 무엇을 추천한다기 보다는 현장상황에 따라서 모델을 선택해야 한다. 단계적 표현(Staged Representation) 모델은 구조화된 로드맵을 제공하고 조직 간 벤치마킹이 용이하다. SW-CMM과의 호환성도 좋고 평가결과가 간결하여 규정 준수 등이 필수적인 분야나 체계적인 프로세스 기반이 부족한 초기개선조직에 어울린다. 반면 연속적 표현(Continuous Representation) 모델은 프로세스 영역을 선택집중할 수 있어 유연하고 역량 수준에 따른 점진적 개선을 할 수 있다. 또한 복잡한 프로젝트 환경에 더 어울려서 기 성숙한 조직 또는 맞춤형 개선이 필요할 때 더 많이 쓰인다.
 
구분 단계적 표현 모델 연속적 표현 모델
선호도 높음(특히 국내) 낮음(해외, 고도화된 조직)
장점

구조화된 단계별 접근
벤치마킹 용이

유연한 개선
특정 PA 집중 최적회

단점

유연성 부족
모든 PA 강제 적용 필요

평가 결과 복잡
초기 조직 적용 어려움

적합 조직

규제 준수 필요
초기/중소 조직

성숙 조직
복잡한 프로젝트 환경

 
이런 특징들로 국내에서는 어떤 모델이 더 선호대상인가? 국내는 단계적 표현모델이 더 인기가 있다. 그 이유는 여러 배경들이 있겠지만 우선 숫자로 명확하게 표현되는 등급체계가 인증을 우선 시 하는 문화와도 결부되어 있고 SW-CMM기반의 기존 개선모델에 대한 경험, 그리고 평가가 간소하다는 것이 실무자들에게 더 높은 평가를 받는 면이 있지 않나 싶다.
 
 
 
 
※ 무슨 말인지는 알겠으나
CMMI를 도입하고자 결정이 나면 해야 할 일이긴 하지만도 지금 일도 많고 바빠 죽겠는데 또 하나의 혹이 달린 것 같아 현장에선 뜨미지근하다 못해 험한 말도 나온다. 그래서 전담조직을 만들고 선단에서 정리를 해나가며 현업들을 설득하는 자리를 빼놓지 않는다. 그러다 보면 일이 힘든 것이 아니라 사람이 힘들다는 것을 뼈저리게 느낀다. 으…. 정말 사람이 전부다. 언제부터인가 사람은 고쳐 쓰는 것이 아니라는 말이 유행처럼 나돌기는 하는데 이 말이 정말인가 다시 한 번 곱씹어보게 된다. 그리고, 나를 돌아보게 된다. 나는?

CMMI (1) (프로젝트 성공률 1% 높이기)

CMMI: Capability Maturity Model Integration

프로세스 개선을 위한 접근방법인 CMMI. 한마디로 말해 조직의 프로세스 개선 활동을 효율적으로 지원하기 위한 모델이다. 좀더 살펴본다면 기존의 CMM은 조직의 프로세스 능력을 어떠한 방향으로 발전시켜 나가야 하는지에 대한 비전을 단계적으로 제시하는 것이라 한다면 통합(Integration)은 기존 여러가지의 CMM모델들을 하나로 정리했다는 것을 의미한다.
 
그동안 SEI(Software Engineering Institute: 소프트웨어 엔지니어링 연구소)에서는 소프트웨어 엔지니어링이나 시스템, 소프트웨어 획등 등에 관한 많은 CMM 모델을 개발해왔고 이를 많은 기업과 프로젝트에서 적용하여 활용했다. 그러나 대부분은 복잡하고 관리가 힘든 여러 모델 대신 하나의 모델로 프로세스를 관리하길 원했고 그 결과로 CMMI가 만들어진 것이다. 
 
CMMI는 단순히 모델을 통합했다는 것 이상의 의미를 갖는다. 그 이유는 여러 모델들에서 다르게 사용되던 용어들을 하나로 통일했다는 것과 개별 모델의 프로세스들이 서로 어떤 형태로 관계를 맺고 있는지를 확인하고 일관된 관점에서 재정립했기 때문이다.
 
 

CMMI 적용 이유

조직과 프로젝트 현장에서 CMMI를 필요로 하는 경우는 많이 접한다. 그들이 이야기를 가만히 들어보면 여러 이유가 있는데 수긍이 가는 측면이 많다.
 
♾️ 고객이 원한다.
♾️ 지금까지 CMM를 적용해봤지만 이젠 CMMI고 더 적합하다고 생각한다.
♾️ 프로세스 개선에서 앞서가고자 한다.
♾️ CMMI가 엔지니어링, 소프트웨어 획득, 통합 제품 팀개발 활동 등에 대한 구체적인 방법을 제시한다.
♾️ 그동안 서로 다른 프로세스 평가 및 개선 프로그램을 도입했으나 중복작업에 대한 비용과 혼선이 많다.
 
이런 이유들로 CMMI를 적용해보고 싶은 조직과 프로젝트 현장의 상황은 어느 정도 파악이 되는데 막상 CMMI를 도입하려는 입장에서는 이 또한 매우 어려운 일로 여긴다는 것도 안다. 이를 실제 현장에 적용하기 위해서는 제일 먼저 조직이 준비가 되어 있어야 하며 잘 받아들기 위한 지원체계 또한 제대로 구축이 되어 있어야 하기 때문이다. 타 조직이나 프로젝트에서 성공했다고 해서 섣불리 일을 진행하기가 쉽지 않은 것이다.
 
 

용어 먼저

항상 강조하지만 용어가 최우선이다. 여러 이해관계자들이 모여 하나의 목표를 설정하고 나아가고자 한다면 반드시 서로 합의하고 사용할 용어를 정의해야 한다. 특히 CMMI는 기존의 포괄적인 개념이 아닌 하나의 통합된 환경과 목표를 가지기 때문에 더욱 그러하다. 그럼 가장 중요한 용어 몇가지를 정의해 보자.
 
🚩 모델
: 조직의 프로세스에서 어떤 부분이 잘못되었는지 확인시켜주는 가이드라인. 단순하게 프로세스를 가져와 그대로 적용하는 것이 아니며 어떻게 업무를 수행하는가 보다는 무슨 일을 수행하는가에 대한 사례로 정의된다. 이는 다른 말로 수행했던 여러 성공사례의 모음집으로 말할 수 있다.
 
🚩 조직
: 프로세스 개선 활동을 수행하는 가변적 단위. 가변적인 단위는 퍼즐 조각처럼 더 이상 바꿀 수 없는 개념이 아닌, 레고 블록처럼 다양한 조합을 통해 여러 가지 모양을 만들 수 있는 개념이다. 그러므로 전사 차원에서 프로세스 개선 활동을 수행할 경우 조직은 회사 전체를, 사업부나 부서 차원에서 프로세스 개선 활동을 추진할 경우에는 해당 사업부나 부서를 말한다. 또한 한 사람만으로 구성된 조직도 조직으로 구성할 수 있다.
 
🚩 프로세스
: 하나의 문제를 해결하기 위한 일련의 작업모음. 이 작업들은 수행하는 사람들이 쉽게 이해할 수 있어야 하고 이를 사용하는 모든 사람들이 하나의 일관된 행동을 할 수 있도록 명확하게 정의되어야 한다. 이를 통해 조직에서 발생하는 모든 중복작업을 제거하고 최소화해야 한다. 
 
🚩 CMM
: 능력 성숙도 모델. 소프트웨어를 개발하는 조직을 관리하기 위한 체계로 조직의 프로세스 능력에 대한 목표와 비전을 제시하며 수많은 조직의 여러 활동 중 의미있는 316개의 핵심활동(Key Practice)을 정리하고 이를 다시 그룹화하여 18개의 핵심 프로세스 영역(Key Process Area)으로 구성되어 있다.
 
🚩 프로젝트
: 고객에게 제품, 서비스를 제공하기 위해 요구되는 모든 활동과 자원. 여러 프로젝트가 모여 하나의 프로젝트가 될 수도 있다. 프로젝트는 명확한 목표와 목적을 가지고 반드시 시작일과 종료일이 있어야 한다. 반복되지 않고 유일하며 매우 치밀하고 구체적이어야 한다.
 
🚩이행(Implementation)
: CMMI 개별 프로세스 영역에서 정의하고 있는 활동을 조직 내부에서 수행하는 것으로 하나의 프로세스를 수립한 이후 그에 따라 업무를 수행한다. 내재화로 가기 위한 시작점이자 반복행위이다.
 
🚩내재화(Institutionalization)
: 하나의 프로세스가 조직 문화로 스며들어 모든 사람들이 아주 당연하게 해당 활동을 수행하는 것. 이를 통해 특정 업무를 다른 사람이 와서 수행하더라도 똑같은 방식으로 수행한다면 내재화는 성공한 것이다.
 




 

준비

CMMI는 조직의 프로세스 개선 활동을 지원하기 위한 여러 모델 중 하나이며 기존 모델들의 통합으로 조직의 많은 영역에서 도움을 줄 수 있다. 하지만 다양한 조직과 프로젝트에 적용할 수 있도록 하기 위해서는 포괄적인 개념이나 용어를 사용하고 있기 때문에 이를 적용하기 위하여 충분한 학습과 이해가 반드시 전제되어야 한다.
 
그 이후 해당 조직과 프로젝트의 구체적인 적용 방법에 대해서 한번 더 심사숙고하고 의사결정을 내려야 한다. 물론 단계과 범위에 따라 다르기는 하지만 여기엔 많은 시간과 비용이 들어가며 특히 경영진의 관심 여하에 따라 이 프로젝트도 성공과 실패로 나뉘기 때문이다. 무엇보다도 경영진의 지속적인 관심이 프로젝트 성공의 관건이다. 남들이 했다고 따라할 것은 절대 아니다.
 
 
 
 
※ 주요국 CMMI 인증 현황
SWSTAT에 따르면 2024년 5월 기준으로, 전 세계에서 CMMI를 인증받은 국가 1위는 중국(11,101건, 레벨5(2,273건), 레벨3(8,783건)), 2위는 미국(1,330건, 레벨5(40건), 레벨3(1,185건)), 3위는 인도(552건, 레벨5(182건), 레벨3(465건))이고 한국은 7위(48건, 레벨5(9건), 레벨3(27건))으로 아시아에서는 중상위권이다. 이렇게 보면 상당히 적게 보이지만 CMMI 인증 유효기간은 3년으로 이를 감안해서 보면 된다.