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

2025년 07월 02일 로 EdP

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

들어가며

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

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

구분	군사(국가/군)	기업(CEO)	부서장/팀장
전략	장기적 전쟁 전체 목표·방침, 방향	기업 비전·장기목표, 경쟁우위 확보를 위한 전체적 방향 설정	부서/팀의 중장기적 목표, 업무방향 설정
전술	구체적이고 단기적인 작전·병력 운용 계획	구체적 실행계획·실무 방법	업무 분장·실행 방안, 일정관리
전투	실제 교전·작전 실행	현장 실적·업무 실행, 실적달성, 고객응대	실무자의 일상 업무, 과업 수행

전략은 2,500여년 전 전쟁을 치루면서 다뤄진 군사용어가 그 기원이라고 한다. 전쟁에 승리를 하기 위해 군대를 배치하고 운영하는 이련의 계획을 뜻했던 전략은 시간이 흐르면서 전쟁 뿐만 아니라 경영, 정치, 스포츠 등 우리 주변의 모든 분야에서 목표 달성을 위한 체계적인 계획과 행동을 담는 함의적인 단어로 사용되고 있다.

여기서는 전략을 경영적 관점에서 기업, 회사, 조직 내에서 주로 다루고자 한다. 위 표에서 보듯 원 기원의 목적은 다음과 같다.

전략: “왜”, “무엇을” 할 것인가에 대한 큰 그림을 뜻한다.
전술: 전략을 기반한 “어떻게” 할 것인가에 대한 구체적 실행 계획을 말한다.
전투: 전략과 전술에 의거한 “실제로 무엇을 했는가”에 대한 행동을 나타낸다.

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

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

2. 전략의 본질과 관점

전략적 의사결정의 핵심

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

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

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

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

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

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

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

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

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

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

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

경영이념

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

비전

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

전략

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

5. 전략수립 프로세스

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

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

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

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

전략수립 프로세스와 요소

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

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

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

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

6. 전략 전환의 타이밍

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

마무리

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

범위 계획 (프로젝트 성공률 1% 높이기)

2025년 05월 31일2025년 05월 12일 로 EdP

“아니 그때 다 이야기된 것 아니었나? 뭐가 이렇게 자꾸 나와?”

프로젝트 범위

무슨 일이든 정해진 범위가 있다. 해야 할 일이 무엇이고 어디까지 해야 한다는, 각각의 일들이 기간을 가지고 있고 우선순위가 있지만 이 모두는 한 박스에 넣어진다. 넘칠 것 같으면 다른 박스에, 아니라면 더 작은 박스로 옮길 수도 있다. 이렇듯 일에 맞는, 범위에 맞는 일을 정해놓지 않으면 서로 얼굴 붉힐 일만 남을 뿐이다.

그럼 프로젝트에서 범위는 뭘까? 범위는 프로젝트가 고객에게 제공해야 할 서비스의 집합체로 계획을 수립하고 통제하는 대상이자 시작점이다. 이에 따라 계획의 적정성, 실현 가능성 및 구체성이 결정되고 범위가 변경된다고 하면 다른 영역들에 지대한 영향을 미친다. 예산이 모자를 수도 있고 투입인력이 탈출할 수 있으며 프로젝트 자체가 폐기될 수도 있는 중차대한 일이다.

프로젝트 범위는 그만큼 중요하다. 그래서 이의 관리를 위해 기본방침으로 잡는 것들이 있다. 첫째. 꼭 필요한 일들로 범위를 최소화하는 것이다. 총합으로서 또는 이를 구성하는 단계 내 범위를 최소화, 군집화하는 것이다. 둘째. 범위의 변경 또한 최소화한다. 범위가 변경되면 작업이 중단되거나 계획을 다시 수립해야 하고 많은 재작업이 발생할 수 있기 때문이다. 셋째. 불필요한 작업을 방지해야 한다. 특히 고객의 요구사항을 제대로 파악해야 하며 이를 통해서 고객의 지나친 요구사항들을 제어해야 하기 때문이다.

범위의 계획

범위 기술서가 우선 필요하다. 수많은 입력값을 토대로 작성한다. 입력값들은 프로젝트 착수 단계에서 고려된 계획과 제약사항들을 분석하여 의사결정과 이해관계를 정리하는데 중요한 단서가 된다. 이러한 일련의 일들은 PM이 주로 작성하고 여러 수행조직과 고객에게 프로젝트 범위에 대한 합의 기준, 의사소통 기준 및 프로젝트 종료 기준을 마련하는 목적을 갖는다.

여기서 범위 기술서는 WBS나 SOW와 차이점이 있다. SOW(Statement Of Work)는 보통 작업지시서, 작업 기술서 또는 시방서라 부르며 공급할 제품/서비스에 대한 상세한 설명을 담고 있다. WBS(Work Breakdown Structure)는 말 그대로 업무 분해 구조로 범위 기술서에 정의된 정보를 바탕으로 제품/서비스를 개발하는 과정에서 필요한 여러 단계의 작업 요소들을 상세하게 구성하고 조직화하는 것이다. 그래서 범위 기술서로 범위 기준을 설정하고 이 내용을 바탕으로 작업을 지시하며 이 작업을 수행하기 위해 범위를 정의하고 관리 틀을 만들어 운영한다고 보면 된다.

범위의 정의

프로젝트 범위를 한눈에 볼 수 있는 것이 뭐가 있을까? 앞서 이야기한 WBS가 이 범위를 산출물 중심으로 프로젝트 여러 요소를 군집화해 보여준다. WBS는 반복되는 분할로 더 작고 관리하게 편한 크기로 작업을 나눠 프로젝트 산출물을 체계화했다고 보면 된다. 이는 보통 PM과 프로젝트팀에서 작성하는데 이를 통해 프로젝트 전체를 조망하고 관리할 수 있는 매우 중요한 문서이다.

그래서 WBS는 외부적으로 PM과 고객, 내부적으로는 PM과 상위 관리자 간의 실질적 계약으로 볼 수 있으며 모든 계획의 근간이 된다. 그래서 정해진 업무 외 추가적인 요구사항이 나온다면 그 수용 여부에 대해서 고객을 설득할 수 있는 증거물로도 그 역할을 톡톡히 한다.

WBS 작성은 범위 기술서를 바탕으로 한다. 목적을 염두에 두고 기능요구사항을 정의한 뒤 이의 달성을 위해 주요 액티비티를 정의한다. 이후 관리를 용이하게 하고 누락을 없애기 위해 계층적 분할을 하며 조직화하고 군집화한다. 여기까지 되었다면 일정을 산출하고 원가와 연계시킬 수 있으며 진척도를 관리할 지표로 사용할 수 있다.

WBS (Work Breakdown Structure)

WBS의 핵심 구성요소에는 Work Package(작업패키지) 가 있다. 이는 측정 및 관리가 가능한 WBS 최하위 작업 요소라고 보면 된다. 즉 분할의 최소단위인데 보통 80시간(2주) 내의 기간을 가지게끔 분할 규모를 설정한다. 또한 유일한 ID로 관리하는데 이를 Code of Account라고 한다. 전체적으로 보면 프로젝트 – 단계(Phase) – 작업(Task) – 작업패키지가 그것이다. 산출물 또한 중요한데 이것은 액티비티의 결과로 만들어지며 최하위 작업패키지에 매핑한다.

그래서 작업패키지를 어떻게 잡는가가 관건인데 의 적정 수준은 크게 두 가지로 본다. 첫째. 너무 개괄적인 분해는 아닌지? 둘째. 너무 세밀한 분해는 아닌지? 이렇게 보면 어떻게 잡으라는 말인가 하고 의문이 들 수 있는데 이 역시나 경험이 필요하다. 어느 하나 똑같은 경우는 없으며 프로젝트마다 모두 다르기 때문에 많은 시도와 결과를 통해 적정한 규모로 만들어가는 노력이 필요하다. 다만 이를 평가하는 일종의 법칙이 있다.

하나는 1~10%의 법칙인데 전체 프로젝트 기간을 영업일 기준으로 산정하고 여기에 1%에서 10%의 범위로 규모를 나누는 것이다. 또 하나는 1보고 기간의 법칙이다. 이는 작업 지연을 최소화하기 위한 것으로 프로젝트 최소 감시 주기 이내로 작업을 분할하는 것이다. 예를 들어 주간 보고가 최소 감시 주기라 하면 이 이상을 벗어나는 작업은 마지막에 가서야 결과를 통보받을 수 있기 때문에 그 위험성이 증가할 수 있는 것이다.

※ WBS 만들기

요즘 툴들이 너무나도 좋아져서 기본적인 내용만으로도 작업이 가능하다. 하지만 말이 좋아 그렇지 WBS를 만드는 일은 만만하지 않다. 역시나 어디까지 할 일을 분할해야 하는가에 대한 고민은 머리를 빠지게 한다. 그래서 여기서도 MECE(Mutually Exclusive, Collectively Exhaustive)를 중요하게 쓸 수 있다. 중복됨 없이 하나라도 누락되지 않게끔 정리하고 80시간 이내로 자르며 이것이 최소 감시 주기를 벗어나지 않게만 해도 반은 성공이다. 여기까지도 힘 드는가? 그렇다면 동료와 같이 작성하자. 왜냐면 프로젝트는 나 혼자만 하는 것이 아니니까 말이다.

프로젝트생명주기 (프로젝트 성공률 1% 높이기)

2025년 05월 31일2025년 05월 07일 로 EdP

프로젝트 생명주기!

일을 진행하는 과정에 있어서 그 단계와 절차들이 있는데 프로젝트에선 이를 생명주기(life cycle)로 표현하며 여러 단계(phase)를 통합적으로 지칭한다. 프로젝트 수행조직은 하나의 프로젝트를 여러 개의 단계로 구분, 관리하는데 이 단계는 프로젝트의 구성단위로 볼 수 있고 각 단계는 단계별로 중요한 산출물이 완료되는 시점이다. 이러한 단계는 종료 검토를 통해 다음 단계로 진행할 것인지를 결정하고 이 단계들이 모여 최종적인 프로젝트가 완성된다.

모든 프로젝트는 단계로 나눠진다고 이야기했다. 크든 작든 프로젝트와 상관없이 이 단계들은 일정한 생명주기를 가지는데 큰 틀에서는 엇비슷하다고 볼 수는 있으나 크게는 업종에 따라서도 그 내용이 상이하다. 그래서 동종업계의, 유사 프로젝트 성격을 가진 자료들을 바탕으로 이러한 생명주기를 참고하고 갖춰볼 수도 있다. 그러면서 내 프로젝트에 맞게끔 적용하거나 변경할 수 있다.

프로젝트관리 생명주기?

그간 프로젝트, 프로젝트관리, 생명주기 등 각각의 용어에 대해서 알아보았다. 그렇다면 프로젝트관리 생명주기는 무엇인가? 헷갈릴 수도 있지만 앞선 용어들을 참고해서 의미를 생각해 보자. 프로젝트 생명주기가 아닌 프로젝트관리에 대한 생명주기는 관리 절차, 관리프로세스라고 볼 수 있고 이는 각각 착수, 계획, 실행, 감시/통제 및 종료로 구성된다. 아래를 봐보자.

🚩착수
: 프로젝트의 시작이다. 고객이 프로젝트의 발의를 결정하고 수행조직에 전달되어 준비되는 이벤트이다. 첫 시작이기 때문에 이것저것 챙길 것이 많다. 그중에 몇 가지만 추려보면, 프로젝트 요구사항분석, 예비 범위 확인, 일정/예산 산정, 제약조건 확인, 이해당사자 분석, 성과기준 마련, PM 결정과 권한 부여, 팀 꾸리기 등이 있다. 이 모든 예비작업이 정의되고 기술되어 Big Picture로서 프로젝트계획이 수립된다.

🚩계획
: 앞서 그린 큰 그림을 바탕으로 프로젝트를 세세하게 계획한다. 프로젝트 관리계획, 실질적인 범위 기술서, WBS(Work Breakdown Structure), 각각의 액티비티와 우선순위, 기간, 자원할당, 비용산정, 품질계획, 인력/의사소통 관리, 위험관리 등 관리의 추상화 레벨을 내려가며 할 일들을 정리해 나간다. 이 계획들이 빠짐없이 세세하게 구축이 되어야만 프로젝트의 성공률을 끌어올리는 실마리가 될 수 있다.

🚩실행
: 이제 본격적인 활동의 시작이다. 프로젝트 구성원들에 대한 다양한 기초교육을 바탕으로 유관 조직, 기관, 업체들에 대한 선정 내지 작업지시, 본격적인 품질보증 활동을 토대로 도입된 방법론에 따라 지속적이고 점진적인 진행을 시작한다. 어떻게 보면 실행은 전체 프로젝트에서 약 20~30%에 해당하는 단계이다. 나머지 70~80%는 단순하게는 문서 형태로 귀결되는 모든 단계의 활동 산출물들이 담당한다. 근래에 들어 이런 부담을 줄이는 경량화되고 빠른 방법론들이 사용되고 있다. 다만 모든 경우를 포괄하는 것은 아니다.

🚩감시/통제
: 프로젝트의 빅브라더가 해야 할 일이다. 매 단계의 성과를 품질 기반으로 측정하고 진척을 관리한다. 문제가 발생하면 시정조치와 피드백을 받고 그 효과성을 평가하여 프로젝트에 재귀적 반영을 한다. 변경에 민감하며 비용을 통제한다. 위험 유발요인을 집요하게 추적하며 모든 활동을 감시한다. 감시라는 용어가 다소 거부감이 들 수도 있지만 감시가 몇몇 관리자가 하는 행위뿐만 아니라 프로젝트 모든 구성원이 해야 할 일이기에 그렇게 생각할 필요는 없다. 성공하고자 한다면, 성공의 책임은 모든 이해당사자 각각이다.

🚩종료
: 대망의 마무리 단계. 그간의 업무들을 총체적으로 정리, 마감한다. 산출된 결과물들을 고객에게 인도하고 승인을 득하며 프로젝트 전 과정을 통해 배울 것들, Lessons Learned를 문서화하고 공유한다. 점유된 자원들을 하나둘 해제하며 프로젝트는 서서히 끝날 기미를 보이며 종료된다. 완료 평가와 함께 최종 보고를 하고 고객관리 방안과 미결사항 등에 대한 복안을 논하고 오랜 시간의 마침표를 찍는다.

Project Management Lifecycle
< 프로젝트관리 생명주기 >

관리영역들

업무를 하면서 우리 알고 있는 PDS, 즉 Plan – Do – See와 다르게 프로젝트는 시작과 끝에 따라, 여러 특성과 환경 등에 따라 그 생명주기는 각기 다르다. 그래서 앞선 5가지는 세부적으로 여러 가지 프로세스들로 구성되어 있다. 이는 흔히 PMBOK(Project Management Body of Knowledge, 현재 7판)이나 SWEBOK(Software Engineering Body of Knowledge, 현재 4판)등에 자세히 나와 있다. 프로젝트에서 이것을 모두 활용하기엔 다소 무리가 있고 그중 가장 핵심적인 단계들만이라도 제대로 관리한다면 프로젝트 성공률은 높아질 수 있다. 세세한 내용은 차차 다루기로 하고 여기서 알아 둘 것은 크게 두 가지이다. 프로젝트 목표 달성을 위한 Core 프로세스는 원가, 일정, 범위 단계, 그리고 목표 달성을 위한 수단으로써의 Facilitating 프로세스는 품질, 인력, 의사소통, 위험, 아웃소싱단계가 그것이다.

※ 한곳을 향해.
PM은 프로젝트를 성공적으로 완수하고 싶다. 격하게 하고 싶다. 그래서 나름의 넘치는 욕심과 의욕으로 시작하지만 높고 낮은 벽들에 계속 부딪히고 싸우면서 점점 의기소침해지고 소극적으로 변하며 전의를 잃기도 한다. 이때 무엇이 필요할까? 멘털이다. 멘털을 잘 붙들어 매어야 나 자신을 지킬 수 있다. 그리고 이걸 옆에서 지켜보는 구성원들은 PM을 이해하고 지지해줘야 한다. 설사 내부 총질(!?)을 해대는 상황이 발생할지라도 그건 나중 일이다. 팀은 왜 존재하는가?

프로젝트 계획 (소프트웨어 공학)

2024년 01월 03일2023년 08월 11일 로 EdP

프로젝트 문제와 범위 정의

소프트웨어 개발 시 일정이 지연되거나 비용이 초과고 기대했던 품질에는 못 미치는 산출물, 그에 따라는 여러 유지비용의 증가 등과 같은 문제들은 기본적으로 계획의 부재에서 오는 경우가 많다. 개발 일정을 준수하면서 질 좋은 소프트웨어를 개발 생산하기 위해서는 정밀하고 세심한 계획수립이 필요하다. 소프트웨어 개발 프로젝트 초기 단계에서 프로젝트의 목표를 기반으로 여러 불분명한 사안들을 확인해 가면서 계획을 수립하는 것은 매우 어렵다. 하지만 계획작업을 통해 불분명한 목표, 사용자 요구사항 및 제약사항 등을 명확히 하는 것이 필요하다. 이러한 계획은 보통 문제의 범위를 확인, 정의하고 필요한 활동들을 정하며 세부적인 일정계획과 비용을 추정하고 최종적으로 계획서를 작성하는 절차로 이뤄진다.

다시 말해 프로젝트 계획은 대상업무와 문제들을 고객이 이해하는 용어로 정확하기 정의하고 기술하는 것으로 시작한다. 문제는 철저하게 고객의 입장에서 정의되어야 하며 기술관련 전문용어 등을 사용해서는 안된다. 문제를 정의하는 것은 범위를 정하는 것이다. 이는 개발대상의 기능, 성능, 제약조건, 인터페이스 등의 프로젝트에 대한 타당성과 신뢰성 및 초기 계획을 작성가능한가에 대한 판단 근거로 쓰인다. 문제 정의는 제일 먼저 그 배경을 이해하여야 한다. 이를 위해선 고객과의 면담, 현장답사 및 실제 업무를 수행하는 실무자의 실제 업무를 관찰하거나 직접 수행을 해보기도 한다. 그러면서 객관적 시각에 문제를 파악한다. 이 모든 것이 끝나면 문제 해결을 위한 준비를 한다.

일정 계획

일정은 프로젝트 개발에 있어 모든 프로세스를 구성하는 작업들을 파악하여 그 우선순위와 기간을 산정하며 진행한다. 이에 모든 작업들을 수준별로 나열을 하며 산출물이 있다면 각각 기술해 준다. 프로젝트의 규모가 작다면 큰 일이 아닐 수도 있으나 대규모의 프로젝트에서는 작업도출과 더불어 각 작업들 간의 상관관계를 면밀히 검토하여야 한다. 이때 보통은 PERT/CPM을 활용하며 최종적으로 간트차트 등을 사용하여 거시적 관점에서의 일정을 관리할 수 있도록 한다. 이렇듯 소프트웨어 공학은 엔지니어링 작업으로서 정확하고 현실적인 계획을 수립하고 작업 수행에 소요되는 여러 자원들을 최적화하여야 한다. 이에 따라 프로젝트의 진척도를 실시간으로 점검할 수 있고 계획과 비교하여 문제가 있을 시에 다방면의 조치로 문제해결이 가능하다.

간트차트로 보여지는 프로젝트 작업들, 일정표는 그 수준에 맞춰 분해가 이뤄지고 계층적으로 구성하여야 하는데 이를 위해 WBS(Work Breakdown Structure)를 사용한다. 이는 작업들이 모여 소요 일정이 예측되며 이를 통해 프로젝트 전체 일정을 예측할 수 있다. WBS는 큰 단위의 업무를 관리하기 쉬운 작은 단위의 작업으로 나누기 위한 도구이다. 여기서 관리 가능한 작은 작업들은 업무 지시를 하는 단위가 되며 작업시작일, 종료일, 소요기간, 담당자, 필요 자원 등을 병기하여 관리한다. WBS는 일정계획 작업의 입력값이며 작업 분해는 프로젝트가 어떤 작업으로 구성되었는지를 알아내는 것이고 일정 계획은 이들 작업을 어떤 순서로 할 것인가를 정하는 일이다.

소프트웨어 개발모형 선정, 단계별 작업을 분해 후 작업결과 정의
각 작업간 상호의존관계 정리
각 작업소요기간 정의 및 프로젝트 완료에 필요한 최소기간 산출
프로젝트 규모추정을 통한 M/M 산출
확정 결과 정리 및 공유

비용 추정

소프트웨어 개발에 있어 비용을 정확히 예측하기는 매우 어려운 일이다. 특히 계획단계에서는 불분명한 사항들이 많고 여러 환경적인 요소로 비용에 대한 입장차도 존재한다. 그럼에도 불구하고 기준을 바탕으로 수립되는 소프트웨어 개발 비용예측은 특히 투입되는 개발자와 기간에 매우 큰 변수로 작용한다. 이에 과거 프로젝트의 경험이 중요하며 특히 유사 프로젝트가 있다면 규모와 비용, 인력들을 감안하여 예측을 어느 정도 가능하게 한다. 그러므로 정확한 예측은 프로젝트 성공율을 높이는 필수 조건이다. 이에 비용 예측방법도 매우 다양하며 인건비의 경우 소요기간을 기준으로 하거나 프로그램 규모를 기준하는 방법으로 크게 나뉜다.

첫번째 방법은 소요기간 기준이다. 이는 프로젝트 내 작업들에 소요되는 기간을 구하고 여기에 투입인력과 참여도를 반영하여 최종 인건비를 산출한다. 이 방법은 상향식이라 불리우며 단순히 헤드카운팅이라고도 하는데 시스템 개발에 필요한 모든 작업에 대한 노력들을 하나하나 계획할 수 있는 장점이 있으나 객곽적이 못한 추정 가능성이 있을 수 있다. 두번째 방법은 하향식으로 프로그램 규모를 추정하고 과거 경험을 바탕으로 예측 규모에 대한 소요인력과 기간을 추정한다. 프로그램 규모는 원시코드의 라인수(LOC)나 시스템의 기능을 정량화한, 좀더 복잡한 기능점수(Function Point) 등올 산출할 수 있다.

조직 구성

경영관리에서 조직이란 개개인의 역할을 잘 정의하고 할당하여 프로젝트 목표 성취를 하기 위한 것이다. 이는 기업이나 단체 등 다수의 사람이 모여서 하나의 목표를 이루기 위한 방안으로 조직이 생겨난 것이다. 이러한 조직 구성의 목적은 공통된 목표를 위하여 상호 협력을 하는 것으로 프로젝트에서도 동일하게 적용된다. 이런 조직구성은 조직의 생산성과 효율에 얼마나 많은 영향을 미치고 그 결과가 어떻게 나타나냐에 대한 근본 원리를 따진다. 소프트웨어 개발 프로젝트에서 소프트웨어는 타 제품과는 다른 특징들로 인해 어떠한 조직을 구성하여 진행했느냐에 따라 소프트웨어 개발에 많은 영향을 미친다. 즉 소프트웨어의 품질을 향상시킬 수 있는 소프트웨어의 특성을 잘 살린 조직 구성이 필요한 것이다.

조직의 선택에 영향을 주는 요소는 비용 예측에 사용되는 요소와 유사하다. 알맞은 조직 구성은 프로젝트 기간과 매우 밀접하다. 장기 프로젝트의 경우 구성원들의 사기를 높이고 이직과 이탈을 막기 위하여 개개인의 만족도가 중요 시 된다. 경험이 많은 인력과 적은 인력이 적절하게 섞여야 하며 상호 간 배우고 배울 수 있는 관계 설정도 필요하다. 대규모 프로젝트의 경우 요구의 변경과 명세가 어려운 특성으로 인하여 프로젝트 후반에 신규 인력을 투입하면 일정은 그만큼 지연된다. 이는 인력 상호 간 의사소통의 통로 이슈와 기존 업무의 인수인계 등에 따른 시간을 고려한다고 해도 해소되지 않는 난제이다. 다시 말해 작업의 특성과 조직 구성원 사이의 의사소통의 횟수는 조직의 규모에 맞춰야 하며 필요 이상의 결과에 집중하지 않게 적정 선을 지키는 것이 중요하다.

프로젝트 팀 구성에 영향을 주는 다른 요소는 작업의 특성 및 팀 구성원 사이에 의사교류의 횟수이다. 의사소통이 원활할 수 있는 조직규모와 인력수는 매우 밀접하며 프로젝트의 복잡도와도 긴밀하다. 이에 공식적인 모형과 인원수도 산출할 수 있는데 중요한 것은 생산성에 촛점을 맞춘 균일한 규모의 조직을 구성하는 것이다. 이 규모는 소프트웨어의 특성과도 연계가 되며 팀은 원칙적으로 작업 수행에 제일 타당하게끔 조직되어야 한다. 그러기 위해선 관리자의 권한과 더불어 일정, 예산, 품질 등 여러 요소를 고려하여 조직 구성방법을 결정하여야 한다. 특히 소프트웨어 개발 팀구성은 의사결정권이 누구에게 있느냐에 따라 구별되며 리더의 역할, 권한, 의무에 따라 크게 3가지 형태의 구성방식을 갖는다.

중앙집중형: 하나의 관리자의 지휘에 따라 움직인다. 기업 조직 내 일반적인 계층형 조직으로 상하관계가 명확하여 대규모 조직보다는 소규모 조직에 적합하고 이의 모듈화로 규모를 키울 수 있다.
분산형: 의사결정을 민주주의식으로 하며 모든 작업은 공동의 작업이다. 팀 구성원 각자가 서로의 작업을 검토하고 타 구성원의 작업결과에 대하여 책임을 진다. 다만 의사소통 비용이 많이들며 이에 따른 생산성 문제가 있다.
혼합형: 중앙집중형과 분산형의 단점을 보완하기 위해 구성된다.

위험분석

위험 분석은 프로젝트에 내재한 위험 요소를 인식하고 그 영향력을 분석하여 관리하는 활동이며 프로젝트를 성공시키기 위하여 위험 요소를 사전에 예측, 대비하는 모든 기술과 활동이 포함된다. 위험 요소에 대해 적절히 관리하지 못하면 프로젝트는 실패할 수 있다. 초기 단계에 위험 요소를 인식하고 그 영향을 분석하였어도 이를 다루는 일관성 있는 계획이 없으면 실패하기 쉽다. 이러한 위험을 줄이는 효과적인 방법은 프로토타이핑이나 점증적 개발 방법 있으며 중간 변경 위험을 대비하기 위한 모듈화도 생각해 볼 수 있다.

< Boehm(Barry William Boehm, 미국 소프트웨어 엔지니어 및 교수, 나선형 모델 제)이 제시한 10가지 위험 요소와 관리 기법 >

인력부족: 유능한 인력 수급, 팀구성, 교육
비현실적 일정/예산: 구체적 비용/일정 예측, 원가분석, 재사용
잘못된 기능의 SW개발: 프로토타이핑, 조직/직능분석
잘못된 I/F개발: 프로토타이핑, 타스크분석, 시나리오기법
과포장: 프로토타이핑, 원가분석, 비용수익분석
계속적인 요구변경: 최대변경상한선, 점증적 개발
외부 모양 빈약: 벤치마킹, 성숙도분석
외부 기능 빈약: 사전검증, 대조확인
실시간 성능 빈약: 벤치마킹, 튜닝, 시뮬레이션
기술적 취약: 기술분석, 비용수익분석