프로젝트

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

로

리더십
리더십(Leadership)은 리더 한 사람이 공통의 과제를 달성하기 위해 다른 사람들로부터 지원과 도움을 받는 사회적 영향의 과정으로 지도력, 영도력 등으로 불린다. 리더십은 나 자신부터 시작하여 누가 나가 보여 줄 수 있으며 사회 곳곳에서 찾아볼 수 있다. 리더십은 권위가 아니며 특히 특정 목적을 가지고 정해진 일정과 목표를 달성하기 위한 프로젝트에선 매우 중요한 요소 중 하나이다.

이 리더십의 대상이 되는 프로젝트라는 조직은 다양한 사람과 많은 기능이 결합하여 움직이는 유기체이고, 리더십은 이러한 조직이 올바른 방향으로 변화하도록 촉진하는 역할을 한다. 변화를 위해 프로젝트 조직을 설치하고 개편하는 것 등은 비교적 단기간에 해낼 수 있지만 실질적인 변화는 구성원들의 신념과 가치의 영역에서 일어나야 한다. 다만 프로젝트는 그 규모와 일정에 따라 보통은 중단기 정도로 움직이기 때문에 진정한 리더십을 발휘하는 것이 힘들 수도 있으나, 그런데도 진정한 리더십의 구현이 가능하다고 본다.

이렇듯 조직의 변화를 시도하고 끌어내 가면서 나타나는 리더십의 역량은 결과로 말하고 결과는 관계로 대표된다. 그러므로 리더는 자신을 비평에 노출하는 용기와 결단을 내보일 때만 다양한 창의성과 변화의 기회가 조직에 스며들 수 있다.

 

리더십 역량 구성요소
변화를 위해 필요한 행동 특성의 모음인 리더십은 다른 사람과의 상호작용을 통해 학습할 수 있고, 리더가 다른 사람과 상호작용하는 방식은 프로젝트에 영향을 주며 반대로 프로젝트가 리더십에 영향을 주기도 한다. 즉 리더십과 프로젝트를 따로 구분해서 생각할 수 없으며 사람의 관계 속의 이 리더십은 보통 5가지 역량 구성항목으로 볼 수 있다.

① 방향 제시 : 구성원에게 분명한 방향을 제시하고 책임을 진다. 모든 자원을 긴밀하게 조직화하고 다른 사람이 과제를 완수할 수 있도록 적극적으로 지원한다. 지원은 유무형 모든 것을 포함한다.

② 임파워먼트 : 다른 사람이 주도적으로 일할 수 있는 동기와 여유를 주고 업무를 성공적으로 완수하도록 권한과 위임을 적절히 부여한다. 확신의 과정인 이것은 나아가 상호 믿음의 영역이기도 하다.

③ 동기부여 : 분명한 목적의식으로 사람들에게 동기를 불어넣고 성공적으로 목표를 성취할 수 있도록 촉진한다. 또한 일에 대한 긍정적 태도와 성공하고자 하는 욕구를 일깨워 자발적 협력을 모색한다.

④ 인력개발 : 건설적 피드백과 코칭, 교육, 여러 능력을 적용해 볼 수 있는 과제를 제공하여 다른 사람의 기술과 재능향상의 기회를 도모하고 개발을 격려한다.

⑤ 인재 확보 : 탁월한 인재를 찾기 위한 모든 수단과 방법을 모색하고 그들의 개발을 위해 시간과 노력을 투자한다. 일은 결국 사람이 하는 것으로 사람이 핵심임을 인식한다.

 

리더십 스타일
리더십은 원하는 결과를 얻기 위해 프로젝트 내외부의 개인에게 영향을 미치는 태도, 재능, 성격 및 행동으로 보여지고 프로젝트는 효과적인 리더십에 대한 요구사항이 많다. 일반적이고 일관된 사업과 달리 프로젝트에는 정기적인 상호작용을 해야 하는 이해당사자는 적고 수많은 이해관계의 기대치가 공존한다. 결과적으로 관리자, 경영진 및 기타 이해당사자들이 프로젝트에 서로 영향을 미치려고 한다. 이는 종종 더 높은 수준의 혼란과 갈등을 야기하는 원인인데 이때 필요한 것이 리더십이다.

우리 주변에서 찾아볼 수 있는 성과가 높은 프로젝트에는 효과적인 리더십 기술을 보여주는 사람들을 찾아볼 수 있다. 이들을 관찰해보면 프로젝트에 필요한 결과를 수행하고 제공하는 데 도움이 되는 효과적인 리더십의 특성과 기술, 스타일이 있다는 것을 알 수 있다. 이들은 어찌 보면 인플루언서처럼 행동하기도 하며 각기 보완적인 방식으로 리더십을 최대한 끌어올린다.

앞서 이야기했다시피 리더십은 권위와 혼동되어서는 안 된다. 권위는 권력을 행사할 수 있는 권리이며 특정 활동, 개인행동 또는 특정 상황에서의 의사 결정에 대한 책임을 나타낸다. 그래서 리더십과 비슷하다고 볼 수도 있으나 공동의 목표를 향해 조직에 동기를 부여하고, 개인의 이익을 공동의 노력에 맞추도록 영향을 미치며 개인이 아닌 프로젝트로서 성공을 거두려면 이때는 리더십이 필요하다.

효과적인 리더십은 다양한 스타일의 리더십 스타일을 가지며 흔히들 독재적, 민주적, 자유방임적, 지시적, 참여적, 독단적, 지지적, 독재적이라는 말들로 표현되는데 이 모든 것 중에서 보편적으로 가장 좋거나 권장되는 접근 방식으로 입증된 단일 리더십 스타일은 없다. 대신 효과적인 리더십은 주어진 상황에 가장 잘 맞을 때 나타난다고 보며 이를 통해 리더십은 성장하고 학습되고 개발되며 모든 사람에게 이익이 되는 방향으로 나아가며 여기에는 다양한 기술 또는 기술의 조합을 추가하거나 연습하여 리더십의 통찰력을 강화할 수 있다.

▶ 합의된 목표를 중심으로 프로젝트에 집중!
▶ 프로젝트 결과에 대한 동기를 부여하는 비전 제시
▶ 프로젝트에 대한 자원 확보
▶ 합의 도출을 위한 최선의 방법 제시
▶ 프로젝트 내외부 이해당사자 간 갈등 협상 및 해결
▶ 프로젝트 내 의사소통 스타일과 채널 메시지 조정 및 의사결정 촉진
▶ 팀원 코칭 및 멘토링
▶ 긍정적인 행동과 기여의 인정 보상, 기술 성장 및 개발 기회 제공
▶ 프로젝트팀원에게 권한 부여, 책임 위임
▶ 자신의 편견과 행동에 대한 자각, 실수를 인정함으로써 빠른 실패/빠른 학습 마인드 촉진

그렇다면 유능한 리더는 어떻게 해야 하는가? 위와 같이 하면 된다. 그들은 정직과 윤리성을 기초로 투명성에 초점을 맞추고 비이기적으로 행동한다. 이를 통해 자기 행동으로 기대되는 행동을 또한 입증해야 할 추가적인 책임이 있다. 프로젝트는 리더가 사람들에게 동기를 부여하는 것이 무엇인지 이해할 때 가장 잘 작동하고 모든 구성원이 특정 요구사항과 기대에 부합하는 적절한 리더십이 발휘될 때 프로젝트가 성공할 수 있다.

프로젝트 스타일은 리더의 스타일을 따라가고 스타일은 하나가 아닌 복합적으로 나타나기 때문에 이를 잘 혼합하고 기술 성장을 독려하고 지속하며 동기 부여자를 활용함으로써 모든 프로젝트 구성원 또는 이해당사자는 역할이나 위치와 관계없이 하나의 목표에 접근할 수 있다.

 

 

※ 그래서 리더십이 뭔데?
질문은 쉽지만 대답하기는 어렵다. 그만큼 특정할 수 없는 특징들이 많고 정해진 정답이 없다고도 볼 수 있다. 다만 그 과정과 결과를 보고선 나중에야 판단은 할 수 있을 것이다. 그러나 다시 한번 묻는다면 리더십은.. 연속성이 아닐까 한다. 그 연속성은 리더십이 갖춰지기까지, 그리고 발전해 나가는 그 모습을 계속 지켜나가는 것이다. 대상은 나를 포함하여 다른 사람 모두 가릴 것이 없다. 아이가 성장하는 어른이 되는 것처럼 모자라고 불안할 수도 있지만 믿어주고 함께할 수 있는 어깨가 있다면 세 치의 혀가 아닌 그 모습에서 우린 열렬한 지지와 박수를 보낼 수 있지 않을까? 리더십 부재인 세상에서 남 탓이 아닌 내 탓임을, 내 주변을 먼저 살피며 꾸준함을 견지한다면 우린 모든 선한 영향력을 발휘하는 그, 리더일 것이다.

테일러링 (프로젝트 성공률 1% 높이기)

로

테일러링(Tailoring) 이란?

소프트웨어 개발은 소프트웨어를 생성하고 유지하는 과정으로 다양한 방법과 기술이 사용되며 프로젝트의 특성에 따라 최적화된 방법과 기술을 선택하는 것이 매우 중요하다. Tailoring은 특정 프로젝트의 요구 사항에 대하여 소프트웨어 개발 프로세스나 방법론을 적절하게 조정하고 필요 활동을 가감하는 것이다. 다시 말해, 소프트웨어 개발 프로세스는 규모, 복잡성, 요구사항, 조직 문화 및 프로세스 등 여러 제약 조건에 따라 달라지는데 이러한 요소를 고려하여 프로젝트에 가장 적합한 프로세스를 선택, 조정하는 것을 의미한다.
 
이런 조정의 조치는 소프트웨어 개발 프로젝트의 성공에 핵심적인 요소이다. 모든 것이 목표를 지향하고 나아가지만 100% 수행될 수는 없다. 그래서 프로젝트 진행 중에 발생하는 각종 위험을 줄이고, 품질을 향상하며, 시간과 비용을 단축할 수 있는 방법으로 우리는 Tailoring을 한다. 그래서 Tailoring은 프로젝트 초기 단계에서 고려하고 실시하여야 한다. 프로젝트가 시작되면 진행 중 반드시 새로운 요구사항이 나올 수 때문에 Tailoring을 통해 이러한 요구사항을 미리 반영하는 것이다.
 
 

Tailoring 종류

Tailoring에는 몇 가지 종류가 있으며 이를 통해 부분별로 최적화를 진행할 수 있다. 이는 프로젝트의 특성, 목적, 예산, 일정, 규모, 복잡성, 기술적/사업적 요구사항, 개발역량, 도구, 조직문화 및 각종 제약조건에 따라 고려되고 선택될 수 있다.
 
🚩프로세스 Tailoring
: 소프트웨어 개발 프로세스는 소프트웨어를 개발하기 위한 일련의 단계와 활동으로 구성되어 있는데 이 특성에 맞게 소프트웨어 개발 프로세스를 조정하여 프로젝트 규모에 따라 단계와 활동을 강화 또는 제거하여 효율적인 운영을 하는 것이다.
 
🚩 기술 Tailoring
: 프로젝트 기술 또한 프로젝트의 특성에 맞춘다. 무조건 고급기술을 지향하는 것이 아니라 요구 성능에 적절한 기술을 도입하여 반영하고 운영하는 것이다. 이럼으로써 불요한 기술 비용 등을 줄일 수 있다.
 
🚩 사람 Tailoring
: 소프트웨어 개발 프로젝트의 인력은 프로젝트의 특성에 맞게 조정해야 한다. 개발 프로젝트 난도가 높다면 고경력의 인력을 보다 많이 투입할 수 있는 것이다.
 
 

Tailoring 절차

Tailoring은 개발 프로젝트의 특성을 고려하여 프로젝트의 목표, 범위, 일정, 예산, 인력 및 기술에 따라 어떤 방법과 기술이 필요한지를 판단해야 한다. 이를 위해 다음의 단계를 거친다.
 
✅ 요구 사항 분석

: 프로젝트의 목표와 요구 사항을 분석하고 이해한다. 이를 위해 이해당사자들과의 의사소통, 현장 조사, 문서 검토 등을 수행하여 요구 사항을 명확히 이해하고 프로젝트의 고유한 요소를 파악한다.

✅ 방법론 선택
: 요구 사항 분석을 토대로 조정이 필요한 영역을 파악하고 이에 따른 방법론을 선택한다. 이는 기준이 되는 표준 방법론에서 일부 요소를 선택하거나 다른 방법론을 조합할 수도 있다. 

✅ 프로세스 조정

: 방법론을 조직과 프로젝트에 맞게 조정한다. 이 과정에는 수명주기 단계 추가 또는 제거, 프로세스 세부 조정, 가이드라인과 절차 수정 등이 포함될 수 있다.

✅ 도구와 기술 선택

: 조정된 방법론에 맞는 도구와 기술을 선택한다. 프로젝트에 필요한 특정 기능을 구현하기 위해 특정 개발 도구나 프레임워크를 도입할 수도 있다. 어느 하나를 끝까지 고수할 필요는 없다.

✅ 팀 구성원 역할 및 책임 조정

: 조정된 방법론에 따라 팀 구성원의 역할과 책임을 조정한다. 팀 구성원은 방법론에 맞게 업무를 수행해야 하고 원활한 의사소통과 협업을 진행해야 한다. 팀원들의 역량과 역할에 따라 재조정 또는 새로운 역할을 부여할 수 있다.

✅ 프로젝트 관리 및 모니터링

: Tailoring 된 방법론으로 프로젝트를 관리, 모니터링한다. 이는 일정 관리, 리스크 관리, 품질 관리, 의사소통 관리 등을 포함으로써 프로젝트 진척 상황을 주기적으로 검토하고 필요한 조정을 수행하여 프로젝트 목표 달성을 보장한다.

✅ 지속적 개선

: Tailoring은 프로젝트 진행 중에도 지속해서 개선되어야 한다. 이를 통해 방법론의 효과성과 프로세스의 개선점을 도출하고 반영한다. 
 




 

Tailoring 효과

소프트웨어 개발은 정말 복잡한 과정이다. 이러한 개발 프로젝트를 성공적으로 수행하려면 다양한 요소를 고려해야 하는데 Tailoring이야말로 최상의 결과가 나오도록 모든 것을 잘 매만져 주는 일이다. 이를 통해 프로젝트는 프로젝트의 특성에 맞게 최적화될 수 있고 그 효과는 여러 가지로 나타난다.
 
✔️ 요구 사항 충족
: 프로젝트 특정 요구사항을 위해 방법론이 조정되면 큰 틀에서 매우 효과적인 방법론의 채택을 통해 프로젝트의 속도를 향상한다. 이때 방법론을 처음부터 끝까지 고집할 필요가 없으며 필요 부분에 대해서만 다른 방법론을 활용할 수도 있다.
✔️ 조직 맞춤화

: 고유한 사업적 요구 사항과 제약 조건을 가진 조직은 Tailoring으로 인하여 조직 내 체계를 활성화하고 조직에 맞는 색깔을 찾아 입힐 수 있다. 이에 따라 살아 움직이는 조직으로 보다 유연한 관리가 가능하다.

✔️ 자원 최적화

: 프로젝트 규모와 복잡성에 따라 초기 계획을 지속 관리하고 필요한 자원과 비용을 효과적으로 조절할 수 있다. 즉, 불필요한 자원의 집행을 사전에 확인, 관리할 수 있는 역량을 갖추어 비용과 시간을 절감할 수 있다.

✔️ 프로젝트 성공

: 프로젝트를 성공시킬 수 있는 확률이 높다. 방법론의 수정으로 조직과 프로젝트에 최적화되고 보다 더 적절한 접근 방식에 따라 위험을 완화하고 품질을 향상할 수 있다. 이는 궁극적으로 고객 만족도를 높인다.
 
 
 
※ Tailoring 한계
어떻게 보면 프로젝트 시작과 함께해야 할 Tailoring. 그만큼 중요하다는 것을 알지만 이를 실제로 수행하는 프로젝트나 조직은 매우 드물다. 물론 하기는 하지만 공식적인 형태를 갖추고 제대로 하는 곳이 별로 없단 이야기다. 꼭 이렇게 부르지 않더라도 모든 단계, 조직에서 Tailoring을 하는데 이것이 왜 힘들까? 일단 시간이 없다. 모두 바쁘다. 프로젝트가 본격 궤도에 오르면 앞만 보고 가기에도 힘겹다. 또한 사람이 없다. Tailoring을 제대로 하려면 전문가가 필요하다. 프로젝트와 방법론 전반을 꿰찬 인력은 갈수록 부족하다. 그러다 보니 결국엔 돈이다. 그런데 이런 예산을 기획 단계에서 고려하여 잡아주는 프로젝트가 과연 얼마나 되는가? 결국 핑계? 핑계여서 하지 못한다 한들 해야한다. 누군가는..

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

로

PMO와 역할

PMO(Project Management Office)는 프로젝트와 관련한 관리 프로세스를 표준화하고 자원, 도구, 기법 및 방법론의 공유를 용이하게 하는 관리체계조직이다. PMO는 그 특성과 기능이 조직마다 다르고 같은 조직 내에서도 상이할 수 있으며 프로젝트 작업 지원 방법 또한 다를 수 있다.
 

PMO의 여러 형태와 유무를 떠나 중요한 한 가지는 일정, 비용, 품질, 위험 등의 측면에서 프로젝트 관리를 개선함에 그 역할과 책임이 있다. PMO는 업무를 전략적 목표에 맞추는 데 있어 이해당사자들의 참여와 협업, 인재 개발, 프로젝트 투자 가치 실현 등 많은 역할을 수행한다. 

🚩 프로젝트 포트폴리오를 감독한다. 감독에는 프로젝트 시작을 위한 사례 요구, 프로젝트 제공을 위한 재정 및 자원 할당, 프로젝트 범위 또는 활동 변경 요청 승인과 같은 활동이 포함될 수 있다. 이는 프로젝트의 중앙관리를 지원하고 여러 프로젝트를 담당하여 관리하는 조직에 도움이 될 수 있다.
 
🚩 프로젝트 전달 방법의 일관성을 지원하는 프로젝트 관리 지침을 제공한다. 이는 교육 및 코칭과 함께 여러 지침, 템플릿 및 사례를 제공할 수 있다. 프로젝트에서 표준화된 접근 방식과 도구는 공통된 목적을 더욱더 촉진하고 프로젝트 문제의 의사 결정을 쉽게 한다. 

🚩 계획 활동, 위험 관리, 프로젝트 성과 추적 및 활동을 위한 프로젝트 지원 서비스를 제공한다. 이러한 서비스는 프로젝트에 대한 보다 직접적인 관리를 유지하고 지원을 원하는 독립적이거나 다양한 사업 단위가 있는 조직에서 활용한다.

🚩 평면적이고 고객 중심적인 접근 방식을 갖춘 조직에는 ACoE(Agile Center of Excellence) 이나 VDO(Value Delivery Office) 형태의 조직을 제언할 수 있다. 이들은 관리 감독 기능이 아닌 지원 멘토링 중심의 역할을 수행한다. 

 

주요 기능

PMO는 프로젝트 관리 표준을 제시하고 이를 프로젝트에 적용하며 전체 시스템의 일부로서 지원한다. 이는 프로젝트팀이 결과를 제공하기 위해 특정 기능이 필요한 것처럼 PMO도 마찬가지라고 볼 수 있다.
 
🚩 Big Picture 관점
프로젝트의 목표에 충실히 하는 것은 성공의 핵심 요소이다. 그렇지 않다면 프로젝트는 여러 사유로 목표를 벗어날 수 있다. 이를 위해선 지속적인 목표와 목적을 알리고 공유하며 조직의 전반적 성공을 위한 작업관리 및 평가로 다양한 의사결정을 도와줄 수 있는 정보와 지침을 제공한다.

🚩 성과 지향 역량 확보
프로젝트 관리 기능을 전문적으로 육성한다. 이를 통해 내외부 조직의 여러 이해당사자에 대한 평가를 진행하며 품질의 결과를 신속하고 효과적으로 생성하기 위해 프로젝트의 고유한 특징들을 바탕으로 성과가 더 나올 수 있도록 한다.

🚩 지속적 개선과 변경 관리
정기적인 프로젝트 결과를 공유한다. 이로써 프로젝트에서 얻은 귀중한 지식을 전파하며 참여한 팀원들에 대한 깊이 있는 학습 및 공유 활동으로 역량을 개선한다. 또한 세심한 변경 관리로 프로세스 업데이트, 기능 향상 및 프로젝트 관리를 지원하는 새로운 기술과의 연계를 구축하고 유지한다.

 




 

PMO의 진보

기업환경은 큰 불확실성, 빠른 변화, 더 치열해진 경쟁 구도, 더 많은 권한을 가진 고객으로 조직이 점점 더 복잡해지는 환경에서 기업가치를 창출해야 하는 어려움에 직면해 있다. 이는 수행되고 있거나 계획된 모든 프로젝트에 많은 영향을 끼치며 PMO를 통한 환경개척과 성공적 프로젝트를 위한 차별화된 변화를 원한다. 그에 따라 PMO도 변화를 해야 한다.

🚩 중요 동기 집중
프로젝트 동기는 조직과 프로젝트의 미래, 이해당사자와의 관계 및 역량에 상당한 영향을 미칠 수 있다. 이에 PMO는 그 역할이 관리 감독에서 의사소통을 조율하는 것으로 바뀌고 있다. 이러한 변화는 중요한 전략적 대응에 영향을 미칠 수 있는 프로젝트 성과, 위협 및 기회에 대한 정확한 통찰력을 제공하고 새로운 문제에 대한 명확성과 진로 수정을 촉진하고 사업적 결과를 최대한 실현한다.

🚩 효과적 프로세스 구축
PMO는 낭비적인 단계를 추가하거나 가치 창출 프로세스를 무시하지 않고도 효과적인 의사소통과 협업, 지속적인 개선을 가능하게 하는 충분한 프로세스 및 관행 규칙을 설정하여 조직의 역량을 적절하게 조정한다. 여기에는 퍼실리테이터 중심의 조직화가 필요하고 명확한 R&R을 수행하도록 적극 지원한다.

🚩 핵심 인재 역량
재능 있는 팀원을 모집하고 유지하는 데 보다 적극적인 역할을 수행한다. 인력은 프로젝트를 성공으로 이끄는 가장 중요한 요소 중 하나로 프로젝트 및 조직 전체에서 기술, 전략, 관리 및 리더십 기술을 개발하고 육성한다. 이렇게 길러진 인력은 핵심 인재가 되고 인력풀에서 중장기적으로 관리하고 자산화한다.

🚩 변화 장려
조직의 경쟁 차별화 요소로서 조직의 성과 및 변화 관리에 대한 지원을 부족하지 않게 한다. 이는 모든 구성원에 대한 효과적인 동기부여이자 조직이 살아 움직일 수 있는 근간을 제시하고 그 맨 앞에 PMO가 서 있다. 이를 위해 다양한 이벤트와 정량적, 정성적 활동을 통해 관리 프로세스를 유기적으로 연계한다.

 
 
 
 
※ 그들만의 리그
신경을 쓰지 않는 팀원들이 다수이지만 그들이 누구냐고 묻는다면 그저 사무실 한쪽 방을 차지하고 있는, 맨날 문서만 들고 다니며 회의만 하는 사람들이라고들 한다. 물론 직접 만날 일도 별로 없을뿐더러 대부분 연장자이거나 상사들이기 때문에 내 관심밖에 머물 수 있다. 하지만 그들이 내어놓는 결과물들은 프로젝트 진행에 매우 중요한 역할들을 한다. 그러니 멀리 있더라도 내 관심 영역 안으로 끌어들여 볼 필요가 있으며, 그 사무실에 앉아 있는 ‘그들’도 밖으로 나와 볼 필요가 있다. 정작 필요한 의사소통이 여기에서 제대로 되고 있는지 살펴볼 일이다.

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

로

프로젝트 종료. 유종의 미!

프로젝트란 Kick-off를 한지가 엊그제 같은데 벌써 종료가 코앞으로 다가왔다. 계절도 바뀌고 그간 수많은 우여곡절과 어려움 속에서도 여기까지 온 모두가 대단한 일들을 해냈다. 이제 마지막 남은 업무를 잘 마무리하고 철수를 해야 한다. 철수에 대한 준비는 만만하지 않다. 하지만 중간과정에서 제대로 된 끝맺음과 시작을 했다면 그리 염려할 사항도 아니다. 잘 정리해서 최종 산출물을 별 탈 없이 인도하고 이제 당분간 머리 아픈 일들은 잠시 잊도록 해보자.
 
 

프로젝트 종료 프로세스

프로젝트 종료는 프로젝트 범위 검증, 계약 종료, 프로젝트 종료로 크게 3가지로 나뉜다.
 
🚩범위검증
 : 프로젝트 이해당사자들로부터 완료된 프로젝트 인도물을 공식적으로 인수 승인한다. 이에 범위관리계획서와 더불어 범위 기술서, 인수 대상 목록(WBS), 인도물을 받아 인스펙션을 진행한다. 인스펙션은 인도물이 기준에 충족하는지를 판별하며 여기엔 검토, 검사, 워크스루, 측정 등이 포함되며 이 과정을 통해 인도물을 인수하고 내용 중 문제가 되는 부분에 대해서는 변경 요청 및 시정조치를 요구한다. 인수에는 선 테스트에 대한 통합결과로서 승인의 결과물을 남기며 참여한 인력의 검증을 받는다.
 
🚩계약 종료
: 프로젝트 내 미결사항에 대한 해결 등을 포함하여 프로젝트 종료를 위한 계약을 완료하고 청산한다. 이때 업무도 종료가 되지만 예산에 대한 결과도 마무리한다. 프로젝트에 필요했던 구매관리, 계약관리계획서를 토대로 계약 검사를 진행하고 계약 파일, 인수확인서 등을 챙겨 계약을 종결시킨다. 계약 종료는 말 그대로 행정적 종료이기 때문에 보통은 실 프로젝트 기간 전에 대부분 완료 처리를 하고 후속 건이 있다면 이에 대한 준비를 시작한다.
 
🚩프로젝트 종료
: 프로젝트를 공식적으로 종료하기 위한 관리 프로세스의 모든 활동을 마무리한다. 이를 위해서는 계약종결(제품 검증 포함, 계약 자체 종결) 절차와 행정 종결(프로젝트 기록 및 조직 해체) 절차가 포함되며 계약문건, 성과물을 바탕으로 계약종결, 행정 종결 순으로 마무리한다. 이러한 종료는 단순히 업무가 끝난 것이 아니라 고객과의 신뢰 관계를 구축한다는 의미에서 계획만큼이나 중요하다. 이를 위해 가시적인 절차를 통해 설명하고 이해시키는 과정이 필요하다. 그렇지 않은 경우 여러 문제가 발생할 소지가 있으며 프로젝트가 종료되지 않고 계속 지연이 되는 경우가 발생할 수 있다.
 
   – 최종산출물에 대한 인수 확인 실시
   – 프로젝트 최종 리뷰
   – 프로젝트 보고서 제출
   – 대금 처리
   – 프로젝트 할당 자원 해제 및 철수
   – 프로젝트 파일 보관
 
이 과정에서 인수 회의가 개최되고 프로젝트 최종 리뷰를 실시한다. 최종 리뷰는 프로젝트 계획, 조직, 수행, 관리, 재정 등 모든 분야를 포함하며 성공적인 부분과 향후 개선이 필요한 부분 등을 인식시킨다. 이는 고객이 프로젝트를 내재화하고 추후 개선 가능성을 확인하는 중요한 일이다. 이 자리엔 모든 이해당사자가 참석하여 회의의 목적을 명확히 하고 그간의 노고를 위로하고 서로 축하는 자리의 역할도 수행한다.
 




 

Lessons Learned

회고 또는 교훈. 이는 프로젝트에서 발생한 변경과 그 원인 및 결과를 기록한 문서이다. 프로젝트 변이의 원인, 채택된 시정 조치의 이면 논리, 범위 변경 통제로부터 얻게 되는 교훈들은 해당 프로젝트뿐만 아니라 수행 조직의 다른 프로젝트를 위한 자료 및 베이스라인 설정과 성과측정 기준으로서 반드시 문서화하여야 한다. 이는 추후 기업 및 조직의 자산으로서 지식경영의 근간이 된다. 이러한 마무리에는 특히 성공만이 있는 것이 아니다. 성공을 위한 여러 실패도 매우 소중하게 다뤄야 하며 이런 경험치들이 쌓여 누구도 갖지 못한 무형자산이 될 수 있다.
 
그렇다면 이 교훈을 보다 잘 습득하는 방법은 뭐가 있을까? 이는 프로젝트 전 생명주기를 통해서 얻어져야 하며 매 주요한 단계의 종료 시마다 빠짐없이 리뷰되어야 하며 모든 사항이 정확하고 자세히 분석되고 기록되어야 한다. 그러면서 이해당사자 간 상호 공유를 통해 같은 인식과 목적을 상기시켜 방향성을 잃지 않도록 해야 하는 과정들을 지켜나가야 하는 것이다. 특히나 성공적인 부분들은 Best Practice로서 반복, 적용할 수 있는 자료화하며 성공도 등급을 나누어 차등화할 수 있도록 한다. 
 
프로젝트는 발주자도 그렇고 수행자도 상기의 절차를 통해 모두 종료 과정을 거친다. 특히 맨 마지막 과정으로서 전체 Warp up 시간을 갖는 것은 매우 가치 있는 작업이다. 이는 후속 단계의 작업 시작을 원활하게 해주고 자연스러운 인수인계가 이뤄질 수 있는 실마리를 제공한다. 투입된 팀원들은 성과를 평가하고 경력을 상담하며 추후 건설적 제안이나 권고를 모두가 할 수 있는 통로를 개설하여 활성화한다면 더할 나위가 없을 것이다. 모든 교훈은 자발적 참여와 함께 얻어질 수 있으며 포괄적 사후검토로서 어쩌면 가장 중요한 끝맺음 작업이다.
 
 
 
 
※ 쫑파티!
짧고도 긴 시간의 끝에서 같이 만나고 헤어지는 자리. 그간 혹시라도 맘에 담아둔 것이 있다면 이 자리를 빌려 털어버릴 수도 있고 서로의 고생을 보듬어주는 뜻깊은 자리이다. 하지만 요새는 이런 분위기도 점점 사라지고 있다. 이유야 여럿이지만도 일을 사람이 할지인데 뭔가 섭섭한 마음이 드는 건 어쩔 수 없다. 하지만 형식은 바뀌어도 마음만은 변하지 않았으면 좋겠다. 그래야 사람 사는 맛이 나지 않을까? 더불어 이런 인연들은 시간이 지나더라도 언젠가 또 만나게 되니 있을 때 잘해보는 것도 나쁘지 않겠다. 사실 원수는 외나무다리에서 만난다고 하지 않았는가? 누구도 아닌 나만의 원수는 결국 만나게 되어 있다. 정말 희한하지 않은가? 정말이다..

대가 산정 (프로젝트 성공률 1% 높이기)

로

소프트웨어 프로젝트 대가 산정

소프트웨어 프로젝트를 수행하면서 필요한 대가 산정에 대해서는 한국소프트웨어산업협회가 매년 발행하는 가이드가 있다. 그 이력이 2012년부터 공식적인 가이드가 제정, 공표되었으니 햇수로 벌써 20년을 훌쩍 넘어서고 있다. 일각에선 현장과 맞지 않는 비현실적 대가라고 말하기도 하지만 이러한 기준이 있기에 그간의 사업 진행도 어떻게든 진행이 되지 않았나 싶다.
 
그러면서 지나온 세월만큼 많은 논의와 고민의 흔적들을 보면서 이 또한 받아들이고 응용해 나아가는 지혜가 필요하지 않나 싶다. 이 가이드는 국가·지방자치단체·국가 또는 지방자치단체가 투자하거나 출연한 법인 또는 기타 공공단체 등(이하 “국가기관 등”이라 한다)에서 소프트웨어의 기획, 구현, 운영 등 수명주기 전체 단계에 대한 사업을 추진하면서 이에 대한 예산 수립, 사업 발주, 계약 시 적정 대가를 산정하기 위한 기준을 제공하는 것을 목적으로 하고 있다.
 
대가 산정 활동은 소프트웨어 프로젝트/사업 전체 생명주기 동안 반복적으로 수행되는 활동으로 발주자나 수주자를 비롯한 다양한 이해관계자들에게 큰 영향을 미치는 중요한 활동이다. 이 가이드를 통하여 사업의 합리적이고 객관적인 대가 산정을 유도하여 프로젝트의 품질을 향상하고 제값 주기 환경을 지속 정착시켜 유관 산업 전반의 경쟁력을 높이는 효과를 거두고자 기대하고 있다.
 
 

대가 산정 가이드 구성

본 대가 산정 가이드는 국가기관 등에서 발주하는 사업에 적용되고 공공부문 사업에 참여하는 공급자도 이를 준용할 수 있도록 개발되었다고는 하나 꼭 이 대상들에만 적용된다고 볼 수는 없으며 그 적용 및 활용 범위는 더 넓다고 할 수 있다. 즉, 이 기준에 따라 각자의 영역과 내용에 따라 이 가이드를 충분히 반영해볼 수 있는 여지가 있는 것이다. 
 
가이드는 또 사용자중심의 활용성을 고려하고 있고 프로젝트 생명주기를 따라 프로젝트관리에서 다루고 있는 기획, 구현, 운영 단계로 크게 체계구성을 하고 있다. 다시 말하면 단순히 구현 단계에서의 대가뿐만 아니라 프로젝트 기획 단계부터 운영 및 데이터베이스 구축 프로젝트에서도 적용해 볼 수 있는 내용을 다루고 있다. 이를 통해 사용자의 주요 업무단계에 따라 대가 산정에서 절차별로 설명하고 있는 것을 참고하여 현장에서의 실무 적용이 용이하도록 하고 있고 표준화하였기 때문에 PM을 포함한 프로젝트 이해관계자들도 이를 좀 더 면밀하게 살피고 공부해야 할 만한 이유가 있다.
 
대가 산정에 대한 방법은 가이드에서 다음의 구성으로 되어 있다.
 
✔️ 대가 산정 방식별 개요
✔️ 절차별 주요 내용
✔️ 단계별 설명
✔️ 주요 산출물
✔️ 관련 법령/규정 등 참고자료 및 유의 사항
✔️ 프로젝트 대가 산정 방식별 사례
 
 

대가 산정 가이드 적용 범위

본 대가 산정 가이드에서는 다양한 대가 산정 모형을 가지고 있다. 이러한 모형들은 하나에 국한되어 있지 않고 그 대상이 되는 사업의 유형과 종류, 시점에 따라 적절한 모형을 선택하여 적용하도록 하고 있다. 이에 따른 사업유형의 식별은 다음과 같다.
 
프로젝트 생명주기와 사업유형

< 프로젝트 생명주기와 사업유형 >

 
 
🚩 기획 단계
: 프로젝트 생명주기 상 기획 단계에 해당하는 사업으로 IT 컨설팅 사업(정보전략계획(ISP), 정보전략계획 및 업무재설계(ISP/BPR), 전사적 아키텍처(EA/ITA), 정보시스템 마스터플랜(ISMP), 정보보안 컨설팅 등)이 있다.
🚩 구현단계
: 프로젝트 생명주기 상 구현단계에 해당하는 사업으로 소프트웨어 개발 사업이 해당한다.
🚩 운영단계
: 프로젝트 생명주기 상 운영단계에 해당하는 사업으로 소프트웨어 유지관리, 소프트웨어 운영 및 소프트웨어 재개발 사업 등이 있다.
 
다음이 대가 산정 시점이다. 이는 대가를 산정하는 시점에 따라 가용한 정보의 양과 상세 정도가 달라지므로 해당 시점에 적합한 대가 산정 모형을 선택하여 사용해야 한다. 
🚩 예산확보 단계
: 프로젝트의 예산을 확보하기 위해 사업비를 개괄적으로 산정하는 단계
🚩 사업발주 단계
: 프로젝트를 발주하기 위해 제안요청서 등을 작성하고 발주금액을 산정하는 단계
🚩 사후정산 단계
: 프로젝트가 종료된 후 사전 산정된 사업비와 집행된 사업비의 차이를 파악하여 필요시 정산을 위한 대가를 산정하는 단계
 
 
그럼 이 대가 산정 모형들에 무엇이 있을까? 그리고 각각의 적용 시점은 어떻게 될까? 아마도 구현단계에 집중된 방식을 많이 접하겠지만 이외의 단계에서도 세부 과정에 따른 산정 방법들이 존재한다.
 
♾️ 기획 단계
   – 정보전략계획(ISP) 및 업무재설계(BPR): (업무량/투입공수) 수립비
   – 전사적 아키텍처(EA/ITA): 수립비
   – 정보시스템 마스터플랜(ISMP): 수립비
 
♾️ 구현단계
   – 소프트웨어 개발: 기능점수방식(정통법/간이법)
 
♾️ 운영단계
   – 유지관리 및 운영: 유지관리비, 운영비(투입공수, 고정비/변동비방식)
   – 재개발: 재개발비
 
 

 

기능점수방식(Function Point)

프로젝트 구현단계에서 주로 쓰이는 기능점수방식은 과거 소스 코드 라인을 카운팅하거나 인력수를 가늠하는 방식들에서 점차 발전하여 현재에 이르렀다. 이는 소프트웨어 개발 규모를 기능점수로 측정하고 기능점수당 단가를 적용하여 비용을 산출한다. 다만 모든 것에 적용할 수는 없는 특별한 경우에는 해당 사업의 과업 내용이나 특징 등을 고려하여 발주자의 판단에 의해 투입공수에 의한 방식도 적용할 수 있다.
 
➰ 기능점수방식 산정: (기능점수 X 기능점수 단가 X 보정계수) + 직접경비 + 이윤
➰ 투입공수방식 산정: (투입인력수 X 투입 기간 X 기술자직무별 단가) + 제경비 + 기술료 + 직접경비
 
기능점수방식은 사용자 관점에서의 사용자가 요구하고 사용자에게 인도되는 기능을 정량적으로 산정하는 소프트웨어 규모 측정 방법으로 ISO/IEC 14143(FSM; Functional Size Measurement)으로 SW Size에 대한 국제표준이며, 소프트웨어 개발, 유지관리 및 운영을 위한 비용과 자원 소요를 산정하는 데 가장 중요한 요소이다.
 
 
기능점수란 사용자 관점에서 측정된 소프트웨어 기능의 양으로서, 사용자에게 제공되는 소프트웨어 기능의 규모를 측정하는 단위이다. 소프트웨어 기능은 사용자 관점에서 갖는 논리적 의미에 따라 크게 데이터 측면의 기능과 트랜잭션 측면의 기능으로 구분된다. 이들을 다시 세분하면 데이터 기능에는 내부 논리파일(ILF)과 외부 연계 파일(EIF)의 2가지 유형이 있으며, 트랜잭션 기능에는 세부적으로 외부 입력(EI), 외부 출력(EO), 외부 조회(EQ)의 3가지 유형이 있다.
 
기능점수방식의 산정 방법은 일반적인 기능점수 산정 방법(정통법)과 평균 복잡도를 적용하는 방법(간이법)의 두 가지이다.
 
✅ 정통법
: 소프트웨어 기능을 도출하고, 각 기능의 유형별 복잡도를 고려, 정확한 기능점수 산정을 필요로 할 경우 사용되는 일반적인 방법으로 통상적으로 소프트웨어 개발 공정상 설계공정 후 사용된다.
✅ 간이법
: 기능의 복잡도를 판단하기 어려운 경우 적용하는 방법으로 계산 절차는 정통법과 동일하나 기능점수 산정 시 기능 유형별 평균 복잡도를 적용하여 기능점수를 산출한다. 통상적으로 기획 및 발주단계에서의 기능점수 측정에 사용된다.
 
 
 
 
※ 숫자가 중요하다
사실 대가 산정은 PM이 아니고선 해볼 일이 많지는 않다. 물론 소규모의 프로젝트에선 어깨너머로 본 숫자들을 만져볼 기회가 있기는 하지만 개발에만 전념하는 개발자들 사이에선 기회도 그렇고 이런 숫자 만지기를 꺼리는 사람도 꽤 있다. 하지만 숫자를 보면 알 수 있는 것들이 정말 많다. 개발도 중요하지만 잠시 눈을 돌려 내 주변을 돌아보면 어떨까? 그러면 적어본 본만큼의 시야가 넓어질 것이다. 정말이지 내가 어디에 와있고 여기서 무슨 일을 하고 있는지도 모르고 그저 열심히만 하고 있지는 않은지? 하늘을 봐야 별을 딴다. 내 별이 어디에 있는지 한번 생각해볼 일이다. 요즘은 더욱 그렇지 아니한가?

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

로

제안요청서(RFP)

“프로젝트 성공률 1% 높이기” 두 번째 이야기에서 제안과 관련된 내용을 다루었었다. 그때 제안요청서는 다음처럼 이야기했었다.
 
“사업에 대한 고객의 세부적 요구사항이 정의되어 있고 제안을 위한 기본 틀과 요건을 제시한다. 다양한 형태의 제안서가 존재하지만 가장 중요한 것은 원하는 것이 무엇인지, 이를 통해 최종 결과물의 이미지가 무엇인지 명확하게 제시하는 것이다. 가끔 고객 스스로가 무엇을 할지 제대로 모르면서 부실한 RFP를 내는 경우가 있는데 이건 시장에서도 매력도가 떨어지며 그 누구도 참여할 이유를 찾지 못하기에 이 또한 잘 만들어야 한다. 그러기 위해선 고객도 공부가 많이 되어 있어야 하며 자신들의 약점과 강점을 알고 조직적인 대응을 해야 한다.“
 
즉, 제안요청서는 발주자가 수주자에게 프로젝트의 제안을 요구하는 문서로, 정보시스템의 외주를 통한 획득에 있어 발주자가 용역업체들에 발부하는 것으로 수주자와의 의사전달을 통해 사용자의 요구사항이 무엇인가를 전달해주는 문서라고 말할 수 있겠다.
 
 
이렇듯 제안요청서, RFP는 타당서 조사에서 정리된 기업의 총체적 현실을 대외비라는 명제로 간략히 소개하여 수주대상자들에게 문제에 대한 이해도를 증진할 수 있으며 현재의 문제점을 찾아 극복하기 위한 기업의 요구사항을 상세하게 기술해야 한다. 또한 실제 업무를 진행하는 실무자 선에서 다양한 정보를 분석하여야 하고 많은 시장조사를 통해 사용자에 대한 서비스를 충족시켜야 한다.
 
그리고 개발을 외주에 맡기더라도 공정관리는 물론 프로젝트 전체에 대한 오너십으로 기본방침을 정하고 제안서 작성 요령을 소상히 알려주어 각기 다른 제안구성에 대한 일관성을 견지하는 것이 상호 업무 진행에 차질 없이 효과를 볼 수 있다.
 
 

제안서

제안서는 “프로젝트 성공률 1% 높이기” 두 번째 이야기에서도 또한 이야기했었다.
 
“RFP가 뜨고 나서 사업을 검토 후 제안에 응할 목적으로 작성하는 것. 사업을 어떻게 수행할지 포괄적으로 정리하며 고객이 평가를 통해 결정할 수 있는 근거 자료와 신뢰를 줘야 한다. 즉, 요구사항에 대한 구체적인 방안과 제안사의 사업수행 능력을 명확히 보여줘야 한다. 여기서 최우선은 고객 만족이다. 이를 우선순위로 내용을 작성하며 사업수행을 위한 다양한 투입자원을 고려하여 현실적인 사업 범위를 결정, 제시한다. 특히 경쟁사 대비 차별화는 추후 POC(Proof Of Concept) 나 BMT(Bench Marking Test) 등을 염두에 두고 변별력을 가질 필요가 있다.“
 
제안서는 RFP가 있을 수도 없을 수도 있다. 있다면 그 가이드라인에 따라 충실하게 작성하면 되지만 없다면 내부적인 제안 작성 기준을 따라야 한다. 그런데 그런 기준이 명확히 없다면 보통은 다음과 같은 내용을 포함하게 된다.
 
♾️ 제안서 제출 이유
♾️ 해결해야 하는 문제들
♾️ 문제 해소를 위한 문제점 파악
♾️ 솔루션 제시
♾️ 제안조직/팀/역량
♾️ 비용/일정계획
 
이 중에서 제일 중요한 것은 Why다. 이유를 명확히 하여야 고객은 다음 내용을 읽을 것이기 때문이다. 고객의 pain point를 정확히 파악하여 이유를 제시하고 그 문제를 해결할 문제점을 찾아 솔루션을 제공하는 것. 여기까지만 해도 그 제안서는 성공이다. 이후 비용이나 조직 등 환경적인 부분들은 변경이 있을 수 있고 한 번에 승인되는 경우가 드물기 때문에 큰 틀에서의 제시만 해주면 되고 그보다 고객의 관심을 불러일으키는 것이 최우선이다.
 
제안서의 형식은 보통 6가지 질문에 충실히 답변하면 되는 앞선 내용과 대동소이하다. 제안서 제출조직은 어떤 조직인가, 무엇을 제안하는가, 왜 제안하는가, 어떻게 제안작업이 구현될 것인가, 언제 개발되고 인도되는가, 비용을 얼마나 들 것인가이다. 이렇게 제안받으면 제안서 평가요인과 선정에 관한 절차를 밟아 수주자를 결정하게 된다. 제안평가 또한 평가 기준이 있는데 이는 기술성 기준 검토 등을 통하여 도출하고 각종 문헌 및 전문가의 도움을 받아 설정한다.
 




 

제안서의 설득력

설득은 사람이 사람에게 행한다. 제안서는 설득을 도와주는 도구의 역할을 충실히 하면 된다. 그래서 정보제공과 의미를 모두 내포하여 설득에 참여해야 한다. 그런데 보통 정보제공에 치중되는 경우가 많은데 이는 잘 작성된 제안서임에도 불구하고 설득에 실패하여 수주를 못 하게 되는 것이다. 그래서 문서 이전에 설득에 대한 원리를 알아야 한다.
 
일반적인 설득은 4가지 요소에 의해 결정된다. 그것은 (1) 설득을 하는 사람 (2) 설득 대상자 (3) 설득 경로 (4) 설득 메시지가 그것이다. 설득행위자는 신용과 매력을 가지고 있어야 하고 고객은 믿음과 태도가 중요하다. 효과적인 경로를 통해 고객에게 전달되는 메시지는 명료하고 적절해야 한다. 우린 정보제공을 기반으로 이를 해석하여 설득을 행해야 하는 것이다.
 
 
설득행위자의 고객에게 신용을 증명해 보여야 하며 매력은 고객의 성향을 파악하여 어필할 수 있으나 우선은 신용이 가장 중요하다. 그래서 이것을 제안서의 경쟁력으로 보여줘야 한다. 전달되는 메시지는 내가 아닌 고객 중심으로 전개하여야 한다. 제안서의 핵심이며 고객의 문제, 요구사항에 대한 최적의 솔루션을 제공하는 것이다. 그러면 이것을 어떻게 전달할 것인가? 고객의 요구사항, 이득, 솔루션, 지원사항 등을 명확하고 일관되게 전달한다는 생각으로 소통을 전개한다. 그러면 설득 대상자인 고객에 대한 분석 또한 꼭 필요하다. 이는 사전에 고객의 개인적 성격, 기업/조직문화, 기술 수준, 업무 역할 등을 파악해야 한다는 것이다. 적을 알고 나를 알아야 승리는 거두는 이치는 그것이 무엇이든 똑같다.
 
 
 
 
※ 제안발표
발주자로부터 제안설명회를 안내받으면 그간의 작업을 마무리하고 발표자는 준비를 끝낸다. 그들이 원하는 드레스코드가 있다면 맞춰입고 아니라면 최소한 결례가 되지 않게끔 차려입는다. 말을 다듬고 언어를 정제한다. 손과 발을 맞추고 음색을 고르며 긍정적인 생각을 이입한다. 내가 타 제안자보다 뛰어나다는 자신감을 가져야 하지만 굳이 생색을 낼 필요는 없다. 경쟁력 있는 제안서에 부합하는 자세를 견지하고 타 제안자를 공격하지 않는다. 정성은 기본이나 정량으로 대결한다. 매달리는 것이 아니라 모르는 것을 알려주는 자세에서 승부가 판가름 난다. 겸손하지만 당당하게..

형상 관리 (프로젝트 성공률 1% 높이기)

로

형상 관리

형상 관리는 프로젝트 내 각종 산출물에 대해서 각각의 식별성과 추적성을 확보하고 유지관리하기 위함이다. 이를 통해서 프로젝트 수행 중 제품/서비스에 대한 가시성을 확보하고 PM과 여러 이해관계자의 관리 활동에 도움을 줄 수 있다. 
 
형상 관리의 주요 활동은 프로젝트 생명주기 동안 기준선이 되는 형상 항목을 식별하는 형상식별 활동, 형상 항목의 상태 및 수정 요구를 기록하고 보고하는 형상 상태 보고, 형상 항목의 완전성, 일관성, 정확성을 보장하기 위한 형상 감사 및 검토 등으로 나눠볼 수 있다. 
 
형상 관리와 관련한 몇 가지 주요 용어들은 다음과 같다.
 
♾️ 형상 요소(component): 하나의 시스템의 기본적인 부분
♾️ 형상기준선(configuration baseline): 승인된 기능적 형상 문서
♾️ 기능적 형상 감사(fuctional configuration audit): 형상 항목이 결과물의 기능, 성능, 상호운용성, 인터페이스 요구사항을 만족시키는지 검증하기 위해 인수에 앞서 형상 항목의 특성에 대하여 공식적으로 수행하는 시험
♾️ 형상 항목(configuration item): 형상 관리를 위한 단위로 하드웨어, 소프트웨어 요소들의 집합
 
♾️ 형상 감사(configuration audit): 요구되는 모든 형상 항목이 만들어졌는지, 현재 형상이 명세화된 요구사항에 일치하는지, 기술적 문서화 작업이 완전하고 정확하게 형상 항목을 서술하는지, 모든 변화가 해결되었는지를 증명하는 과정
 
이러한 형상 관리도 다른 작업처럼 착수의 과정을 가진다. 형상 관리착수는 형상 관리 계획수립 및 문서화, 자원확보, 책임과 권한 설정, 훈련 등의 타스크를 가지며 활동의 결과로 형상 관리 계획이 작성된다. 아래는 주요 형상 관리 계획들이다.
 
♾️ 목적, 범위, 정의 등
♾️ 조직 및 (내외부) 조직간 관계, 책임자와 R&R
♾️ 형상 관리 자원(도구, 기법, 방법론 등)
♾️ 각종 정책, 표준, 절차, 보고서 등
♾️ 비용, 일정
 
 

형상식별

형상식별 활동은 프로젝트의 형상 항목을 정의하여 문서화하고 이들의 특성을 기록하는 활동이다. 이를 통해 각 프로젝트의 산출물의 추적성을 확보하고 접근 가능성을 높인다. 이와 관련한 형상 항목에는 모든 소스 코드를 비롯하여 관련 문서, 자료 등 많은 요소가 해당하는데 이를 너무 많이 선정하거나 반대로 너무 적게 선정하면 관리의 어려움이 있다. 너무 많다면 가시성이 낮아지고 너무 적다면 형상 관리 목적을 달성하기 어렵게 된다.
 
형상식별 활동의 타스크는 기능 형상 식별 및 기능 기준선 설정, 할당 형상 식별 및 할당 기준선 설정, 제품 형상 식별 및 제품기준선 설정, 식별의 호환성 식별, 인터페이스 통제 식별, 형상식별 코드 부여 및 각종 기록 등이 포함된다. 이러한 활동의 결과물로는 형상 항목 선정목록, 기능 기준선, 할당 기준선, 제품기준서, 형상 항목 코드 부여 체계, 버전 및 릴리스 관리체계, 기능명세서, 개발 명세서, 제품 명세서, 인터페이스 통제서, 시스템 명세서 등이 있다.
 
— 주요 형상 항목들 —
 
♾️ 소스 코드
♾️ 지원 소프트웨어
♾️ 문서
♾️ 소프트웨어 개발체계, 라이브러리
♾️ 프로젝트 계획, 시험계획
♾️ 형상 관리계획, 절차
♾️ 개선보고서, 형상 관리보고서 등
 




형상 통제

형상 통제는 기준선으로 설정된 형상 항목에 대한 변경 요청을 체계적으로 처리하고 구현하는 활동으로 변경 요청, 조정, 평가, 협조, 승인 및 기각 등의 과정과 밀접하다. 이런 형상 통제의 주요 타스크는 변경 기준 설정, 변경 분류, 변경요청서 준비, 형상 통제위원회 활동, 변경 및 변경 결과 평가, 형상 통제, 변경 관련 문서 및 기록관리가 있고 활동의 산출물은 변경요청서, 변경요청서 검토 및 승인기록, 변경보고서 등이 있다.
 
여기서 변경 기준을 설정하는 이유는 프로젝트를 성공적으로 완수하기 위해 필요한 경우에만 변경을 할 수 있게 하기 위함이다. 이렇게 변경을 할 수 있는 원인으로는 문제점의 수정, 운영상의 변경 또는 요구사항의 변경을 수용, 실질적인 프로젝트 비용 절감 효과 발생, 프로젝트에 중요한 이익을 제공하는 면제 등이 있다. 또한 변경 수준에 대한 분류는 보통 2단계로 구분한다.
 
✔️ 1급: 기능 형상, 할당 형상 혹은 제품 형상 식별 결과에 영향을 미치는 경우
✔️ 2급: 1급 기준 외 철자 오류, 오류가 있는 코드의 재컴파일, 주석의 첨가 등과 같은 사소한 변경
 
PM은 형상 관리계획, 형상 관리 절차, 형상 항목 선정, 변경의 검토/평가, 처리, 승인/기각, 구현 권한을 가지는 형상 통제위원회를 운영하는 것이 좋다. 이 위원회는 형상과 관련한 모든 활동의 대표자로 구성하고 보통은 PM이 임명할 수 있다. 이들은 주요한 변경 필요성, 기술 요소 및 프로젝트 내 모든 이벤트의 영향도를 검토하는 역할을 가진다.
 
 
이러한 과정들이 모두 진행되면 보고 활동한다. 보고는 형상을 효율적으로 관리하는데 필요한 정보를 기록하고 관리하며 적절한 형상 항목이 식별되고 변경 관리가 충실하게 수행되어야 정확한 형상 상태를 보고할 수 있다. 이 활동의 주요 타스크는 형상 상태 기록, 형상 상태 보고이며 활동의 결과는 형상 상태 기록, 형상 상태 보고서가 된다. 이후 감사 활동을 통해 형상 항목이 계약서 등에 명시된 요구사항을 만족하는지를 확인하기 위하여 인수 활동 이전에 형사감사를 행하게 된다.
 
 
 
 
※ 관리 도구
프로젝트를 진행하면서 단계별로 도입되고 운영하는 시스템들이 워낙 많다. 하지만 형상 관리만큼 관리 도구의 역할이 큰 경우도 없다. 이는 사람 손으로 할 수 있는 일이 아니며 여러 도구의 힘이 필요로 한다. 최근 많이 사용하는 관리 도구에는 SVN, CVS, Git 등이 있고 개발자는 개발뿐만 아니라 이러한 도구들을 자유자재로 활용할 수 있는 능력!을 갖춰야 한다. 가끔은 잘 활용하는 사람임에도 항시 사용하는 기능에만 익숙할 뿐 추가로 필요하거나 예외 사항이 발생했을 때 대처를 못하는 경우도 많다. 도구는 말 그대로 누구의 손에 쥐여주느냐에 따라 도깨비방망이도 될 수 있고 똥 막대기가 될 수도 있다. 그러니 공부할 것이 참 많아 행복하지 않은가? (AI도 한 몫!!)

변경 관리 (프로젝트 성공률 1% 높이기)

로

변경 관리

프로젝트가 진행됨에 따라 예상했던 문제를 비롯한 예상하지 못했던 문제와 이에 따른 여러 가능성 또한 발생한다. 이런 것들은 때때로 프로젝트 범위 문서에 대해 변경을 해야 할 때가 있다. 변경 관리는 대부분의 프로젝트에서 잘 지켜지지 않는 부분 중 하나다. 일이 진행되면서 바쁘고 시간에 쫓기다 보니 하나하나 챙기지 못하는 것이다. 이런 것들이 하나둘 쌓이다 보면 심각한 자원의 낭비와 더불어 일정의 지연도 초래할 수 있는 것이다. 그래서 변경 관리는 PM의 입장에서 매우 중요하게 고려해야 할 부분들이 있다.
 
➰ 변경 관리 처리 절차는 명확한가? 예산은 확보되어 있는가?
➰ 변경이 감지되면 유관 문서를 반드시 동기화한다.
➰ 변경의 종류, 처리 방법, 담당자에 대해 인지하고 기록한다.
 
그렇다면 변경의 예들은 무엇이 있을까? 가장 쉽게 만날 수 있는 것은 고객의 새로운 요구사항으로 인해 범위가 바뀌는 것이다. 이에 따라 공수 산정도 다시 해야 할 필요가 있다. 사람들이 하는 일이다 보니 갑자기 인력이 빠진다거나 사고가 날 수도 있으며 수많은 상황에 직면한다. 조직이 바뀌는 경우도 많아 유관부서에 대한 관계나 역할 등을 재설정해야 할 일도 부지기수다. 예산 또한 대내외 상황에 따라 가감이 있을 수도 있으며 작업거점이 변경된다든지 하드웨어에 문제가 생길 수도 있다. 무엇보다도 프로젝트 내 우선순위가 변경되어 전략적 대응이 필요한 경우도 있다.
 
 

변경 관리 프로세스

해당 프로세스는 범위, 일정, 원가, 품질 등 각각의 변경 사항의 관리 내용들을 취합하여 중앙에서 통제하는 형태로 진행이 된다.
 
🚩통합 변경 통제
 : 변경이 발생(필요하거나 이미 발생하였는지)하였는지 확인하고 변경 요청을 검토, 승인하며 승인된 변경만 계획/실행에 반영하여 그에 따른 성과평가 기준선의 정합성과 무결성을 유지한다. 특히 변경 통제를 벗어나는 사안에 대해서는 적극적으로 관여하여 승인된 변경만 반영되도록 해야 한다. 더불어 품질 표준준수에 대한 통제도 함께한다.
 
🚩범위통제
: 범위 변경에 최소화할 수 있도록 범위 변경 요인에 영향을 미치고 변경 발생 시 영향력을 통제한다. 이 부분은 실제 변경 발생 시에 대한 관리를 주로 하며 여러 변경 요인을 파악하고 전후 관계를 살피고 영향범위를 사전에 확인하여야 한다. 즉 갭 분석을 통한 통제로 계획을 변경할 수 있으며 시정사항을 권고하고 WBS를 수정한다.
 
앞서도 언급했으나 범위가 깨지는 이유는 신규 요구사항이 조금씩 추가되는 것이다. 이것은 프로젝트 시작 시 산출물에 대한 불명확한 정의, 해결되지 않고 끌고 가는 의문점들, 모호한 범위의 정의, 이해당사자들의 기대치 상승 등에 기인하는데 프로젝트가 복잡해질수록 눈에 잘 보이지 않고 가랑비에 속옷 젖듯이 점점 프로젝트를 잠식해 들어온다.
 
🚩일정 통제
: 일정 변경을 식별하고 변경이 최소화되도록 하며 발생한 변경의 영향을 관리한다. 이는 프로젝트의 일정을 현 상태를 결정짓는 중요한 활동으로 일정 변경 여부의 결정 또한 이루어진다. 특히 일정은 거시적 관점에서 주기별로 실시간 체크를 진행하며 진도와 성과를 분석하여 통제 우선순위를 결정한다.
 
🚩원가통제
: 원가 변경의 최소화를 위해 영향력을 행사하고 원가 초과 시 가용예산을 넘지 않도록 하며 원가 생산성을 확인하여 추후 원가 상황을 예측하고 이해당사자들에게 전달한다. 원가는 그 변경 요청에 대하여 합의의 도출이 우선되어야 한다. 이를 통해 원가 초과가 예산 범위 내인지를 확인하고 부정확하거나 부적절한 사안에 대해서는 승인 변경에 포함을 방지한다.
 




변경 관리의 단계

변경 관리의 단계는 크게 5가지로 나뉜다.
 
✔️ 변경의 필요성 인식과 평가
: 변경 요청은 항시 PM에 문서화되어 상신되어야 하며 향후 처리 상황에 따라 지속 업데이트를 해야 한다. 업데이트는 기본적인 내용 외에도 변경 요청통보일, 시정조치 여부, 처리상황, 결재 이력이 같이 포함되어야 한다.
 
✔️ 범위, 일정, 예산에 미치는 영향 평가
: 영향 평가에 있어 PM과 이해당사자의 변경 필요성에 대한 동의가 반드시 필요하고 합의하여야 한다. 특히 필수 불가결한 것과 그렇지 않지만 변경 시 효과적인 것들을 나눠서 고려해 봐야 한다.
 
✔️ 관련 조직과 개인에 대한 통보
: 범위, WBS 상 타스크와 일정, 예산 변경에 대하여 유관 조직과 개인에게 통보하고 예상되는 영향을 명확화한다. 범위는 SOW나 WBS를 개정하고 반영, 갱신되어야 한다. 예산 또한 경영층과 재무 관리자도 반드시 알아야 한다.
 
✔️ 승인된 변경에 따른 문서화 및 상태 기록
: 변경에 따라 평가되고 분류된 변경 요청사항들을 문서화하고 프로젝트계획에 통합하여 적용한다. SOW와 WBS를 위시하여 유관한 여러 문서도 동시다발적으로 변경, 적용되어야 한다.
 
✔️ 범위, 일정, 예산 재산정
: 변경이 적용된 후 영향에 따라 범위, 일정, 예산을 재산정하여 프로젝트 내 관련 문서를 수정한다. 관련한 문서들은 주로 프로젝트계획서, 범위 기술서, WBS, 일정표 및 예산지출계획서 등이다.
 
 
 
 
※ 지겨워도
작심삼일이라고 어느 정도 일이 진행되다 보면 여러 이유로 핑계를 대거나 빼먹고 미루기도 하는데 그렇다 하더라도 이를 바로바로 대응하지 않고 쌓아놓다 보면 어느 순간 뒷전으로 밀려나기 일쑤다. 하지만 나 혼자 하는 일이 아니기에 역할을 준다면 어떠한 일이 있더라도 반드시 해야 한다. 우리 모든 것을 기억할 수 없다. 그래서 기록이 중요하고 무언가가 바뀌었다면 그 내용을 꼭 써넣어야 한다. 일일 보고에 주간 보고에 공론화시키고 원인을 찾아 해결책을 찾아가는 건 일 이전에 우리 삶과도 같다.

위험 관리 (프로젝트 성공률 1% 높이기)

로

프로젝트의 위험

위험! 위험은 장기적으로 미래의 어느 순간에 나쁜 영향이나 위험한 순간이 발생할 수 있다는, 즉 발생할 수도 안 할 수도 있는 사건을 의미한다. 다르게 이야기하면 위험은 프로젝트 목표에 불리하게 작용하여 손실을 초래하거나 유리하게 작용하여 이익을 초래할 수 있는 불확실한 사건 및 상황을 말한다. 이러한 위험은 본질적으로 불확실성을 내포하고 있으며 위험의 가장 핵심적인 개념이다. 만약 불확실하지 않고 확실하다면 이것은 위험이 아니라 문제라고 해야 한다.
 
그래서 위험은 예방하는 것이고 문제는 해결하는 것이다.
 
이런 위험은 보통 3가지 요소로 구성되는데 첫째는 발생할 수도 발생하지 않을 수도 있는 특정 어느 사건(Event), 둘째는 그 사건이 실제로 일어날 확률(Probability), 셋째는 그 사건이 실제로 일어났을 경우 프로젝트에 미칠 영향력(Impact)이다. 이 구성 요소들은 위험관리에서 관리되어야 할 중요한 핵심 요소이다.
 
 

프로젝트 위험 관리

앞선 위험과 더불어 위험관리란 프로젝트에 긍정적 혹은 부정적 영향을 미치는 위험 요인을 식별 및 분석하여 이에 대한 대응 방안을 수립하기 위한 체계적인 프로세스이다. 이는 긍정적 사건의 발생 가능성과 파급효과는 극대화하고 부정적인 사건의 영향력은 최소화하는 그 목적이 있다.
 
그렇다면 프로젝트를 수행하는 동안 언제 위험관리가 필요한가? 위험은 프로젝트 초반에 높고 후반으로 갈수록 낮아지게 마련이다. 이는 프로젝트 초기의 총체적 불확실성에 기인한 것으로 개념, 분석설계 및 구현단계를 거치는 시점에서 위험이 가장 높게 발생한다. 이와 더불어 영향도는 초반에는 적다가 후반으로 갈수록 높아지는 성향을 보이며 실행 및 종료 단계에서 그 영향도가 가장 높다. 이는 위험 사건이 발생하면서 영향이 계속 누적되기 때문이다.
 
 
그러므로 프로젝트 위험관리는 프로젝트가 진행되는 동안 지속해서 수행되어야 하며 PM은 위험평가와 지속적 업데이트를 보장하여야 한다. 프로젝트팀은 위험평가를 보고해야 하며 이 보고를 기초로 위험관리계획 또한 개발하여야 한다. 그러나 위험관리의 궁극적 책임은 프로젝트 주체가 지어야 하지만 각 부서에서의 위험은 해당 관리자에게 위임되며 프로젝트 위험은 PM에 위임된다.
 




 

위험관리 프로세스

위험관리 프로세스는 통상 위험관리계획, 위험식별, 위험분석, 위험 대응계획, 위험감시 및 통제의 단계를 갖는다.
 
✔️ 위험관리계획
: 위험관리 프로세스를 프로젝트에서 어떻게 수행할 것인가를 계획한다. 위험의 식별, 정성/정량분석, 대응계획, 모니터링 및 통제를 어떻게 수행할지 구체적으로 정의한다. 이를 위해 위험관리의 접근방법, 데이터 등을 세팅하며 위험의 평가와 통제는 프로젝트 성격, 진행 단계 및 활용 가능한 정보에 따라 상이하다.
 
✔️ 위험식별
: 프로젝트에 영향을 미칠 수 있는 요소를 결정하고 그 특징을 문서화한다. 여기에는 프로젝트와 관련한 이해당사자들이 같이 참여하여 식별한다. 소수에 의한 위험식별은 잘못될 가능성이 높기 때문에 프로젝트팀뿐만 아니라 고객이 함께 참여하는 것이 바람직하며 필요한 경우 해당 분야의 전문가를 참석시키는 것이 좋다.
 
✔️ 위험분석
: 프로젝트 목표에 영향을 미치는 위험 요인의 우선순위를 정하기 위해 각 위험 및 상황에 대하여 분석을 수행, 위험의 확률과 결과를 측정한다. 위험 평가에 있어서는 위험 대응계획을 위한 위험의 규모, 영향력 등을 평가하고 모니터링의 결과로 의사결정을 위해서는 위험의 불확실성을 측정한다. 이때 많이 사용하는 기법은 전문가를 참여시키거나 위험을 등급화하고 의사결정나무분석, 기대 화폐가치(Expected Monetary Value), 몬테카를로 시뮬레이션, 민감도 분석 등이 있다.
 
✔️ 위험 대응계획
: 기회를 증진하고 프로젝트의 목표에 대한 위협을 감소시키기 위한 절차 및 기법을 개발한다. 즉, 위험을 줄이는 계획을 수립하는 것으로 세부적으로는 위험 발생의 가능성을 줄이는 방안과 위험이 발생하였을 때 영향력을 줄이는 방안이 있다. 위험은 부정적인 위험인 위협과 긍정적인 위험인 기회로 나뉘며 위험의 대응도 회피, 전달, 축소, 기회에 대응하는 활용, 공유, 증대, 수용이 있다.
 
이러한 위험 대응 계획 시 참고할 것은 위험은 제거하는 것이 아니며 모든 위험에 대응하는 것이 아니라는 것이다. 또한 위험은 상호 연계되어 있기 때문에 항시 유동적이고 변경이 된다. 위험은 살아있는 유기체라고 보는 것이 맞다.
 
✔️ 위험감시 및 통제
: 프로젝트 생명주기에 걸쳐 잔존 위험 사항을 감시하고 새로운 위험을 식별하며 위험감소계획을 실행하고 이에 대한 각각의 조치 효과를 평가한다. 이는 계획단계에서의 관리계획에 의해 생명주기 전체에 걸쳐 위험을 감시하고 각각의 대응 방안을 실행하고 추적한다. 프로젝트팀은 위험을 감시하고 식별된 위험에 대하여 비상계획을 수행할 수 있게 훈련되어야 하고 PM은 위험관리자를 별도 지정하여 권한을 위임하거나 직접 감리 감독을 해야 한다.
 
 
 
 
※ 항상 깨어 있으라
아무리 주의를 해도 위험은 항시 우리 주변에 도사리고 있다. 위험은 살아있고 그 모습을 쉽게 바꿀 수 있다. 하지만 위험 또한 그 존재의 이유가 있다. 다시 말해 명확한 원인에서 기인한 다형성을 갖는다고나 할까? 그래서 문제의 문제점처럼 위험의 이유를 꼭 찾아야 한다. 그러면 위험이 암세포처럼 퍼져나가는 것을 추적하고 잡을 수 있다. 굳이 쫒아다니지 않더라도 한눈에 위험을 볼 수 있는 것이다. 개안! 그러기 위해선 눈을 크게 뜨고 그 원인을 끝까지 찾아야 한다. 우리 모두 수사관이다.

외주 관리 (프로젝트 성공률 1% 높이기)

로

외주

외주(Outsourcing)는 프로젝트 조직이 해당 업무 또는 기술에 대한 노하우나 경험 등이 부족하거나 개발 인력 또는 예산 등이 부족하여 외부 제삼자에게 대상 업무의 일부 또는 일체를 위탁하여 처리하는 방식을 말한다. 이러한 외주를 고려하는 배경에는 자체 기술력이 미흡 또는 없을 때, 자체 개발 시 예산이 부족할 때, 여유가 없고 시간을 절약하고자 할 때 또 개발인력이 부족할 때 많이 활용한다.
 
근래 들어 외주를 심각히 고민하는 경우는 인력난 때문이다. 코로나 때 더 심화한 인력난은 인력이 당장 필요한 기업에는 재앙 같은 수준이다. 웬만한 기술력이 있는 개발자들은 대기업에서 모두 데려가고 시장엔 사람이 있으나 사람이 없는 상황. 그러다 보니 정규직도 직장을 그만두고 프리랜서로 뛰는 경우도 많이 발생하고 있다. 여기엔 급여가 가장 큰 이유가 되고 있으며 워라밸 등을 중요시하는 풍조도 한몫하고 있다.
 
 
그래서 외주가 더욱 중요해지고 이를 사업화하여 서비스하는 곳도 많아지고 있다. 특히나 사람을 구하기 힘들어지니 정규직이 아닌 외주계약 형태로 지속 운영 중인 곳도 많이 생겨나고 있다. 
 
 

외주계약 형태

외주를 주고자 하는 경우, 계약 시 위임을 할 것인지 파견을 할 것인지부터 프로젝트의 전체 또는 부분을 할당할 것인지 아니면 사람만 필요한 것인지도 사전에 확인하고 판단해야 한다. 그러기 위해서는 외주업체를 선정해야 하는데 크게 두 가지가 있다.
 
✔️ 정량적 기준: 초기 비용, 유지보수 비용, 비용 영향력 등을 전반적으로 고려
✔️ 정성적 기준: 조직 또는 프로젝트와의 호환성, 연계성, 업체의 이전 프로젝트 정보, 외주 관리 수행조직의 역량 고려
 
이러한 외주업체에 대한 평가 방법에도 Survey, 이전 프로젝트 리뷰, 품질시스템 등이 있으며 상황에 따라 적절하게 선택하여 평가한다. 이렇게 업체가 선정된다면 외주계약을 진행하게 된다. 이 과정에서 각자의 입장 차로 시일이 오래 소요될 수도 있고 예외 사항들도 나타날 수는 있으나 기본적인 계약 형태 안에서 보면 다음과 같다.
 
🚩고정가격계약
 : 규정된 공사/서비스에 대한 대가가 확정된 계약이다. 이는 사전에 정의된 공사/서비스에 대해서 고정가격을 정하여 진행하는 것으로 계약 단계에서 제품(공사/서비스)에 대한 정의가 명확한 경우 많이 사용된다. 그렇지 않다면 발주자는 원하는 결과물을 얻지 못한 위험성이 있으며 수주자는 발주자의 요구사항에 따라 추가적인 비용이 발생할 수 있는 위험성도 공존한다.
 
🚩실비정산계약
: 실제 발생한 비용에 대해 지불하는 계약이다. 실비는 보통 직접비와 간접비로 구성되는데 직접비는 이윤이 배제된 비용으로 프로젝트 수행을 위해 직접적으로 소요되는 인건비, 재료비, 경비 등이 여기에 포함된다. 간접비는 사업 수행을 위한 비용으로 수행 조직에 의해 프로젝트에 할당된 비용으로 보면 되며 대부분 경비성의 비용이 해당한다. 이 계약 방식은 고정가격계약 대비 계약 특유의 위험이 없으며 내용 변경 등에 대하여 발주자에게 최대한의 유연성을 제공할 수 있다.
 
🚩단가계약
: 사전에 약정된 단가에 의해 대금을 지급하는 계약이다. 단가가 고정되므로 원가 변동에 대한 위험은 수주자가 부담하는데 단가는 예상 수량을 기본으로 산출하기 때문에 실제 수량과의 오차가 일정 범위 이상으로 커지게 되는 경우 단가를 조정할 수 있도록 유연성을 가지고 계약함이 좋다.
 




 

문제점들

외주계약은 외주를 주기 이전에 내부고객을 대상으로 한 외주로서 생각해 볼 수도 있다. 그렇기 때문에 작업 범위와 목적물에 대한 명확한 정의, 항목들, 예산 및 변경 가능성과 빈도, 업무의 전문성과 표준화 정도를 충분히 따져서 계획을 세워봐야 한다. 그러고 나서 자체적인 역량과 상황에 따라 어떤 부분을 의뢰할 것인지 결정하고 이에 맞춰 업체 선정과 계약이 진행되어야 한다.
 
이렇듯 치밀한 계획과 명확한 목표를 가지고 외주계약이 되더라도 발주자와 수주자 사이에는 여러 문제로 간극이 생길 수 있는데 이는 해결해야 할 문제로 계약 전 상호 인식하고 협의해 나간다면 원만히 진행될 것이다.
 
♾️ 수/발주단계
: 무엇보다 상호 간 의사소통을 원활히 하는 데 장애가 있을 수 있어서 이에 따른 이해도가 부족할 경우가 많다. 또한 용역의 범위와 예산도 조정의 대상이 될 수 있으며 개발자의 능력이나 역할도 중요한 잣대가 되고 정해진 시간 내에 인력을 확보해야 하는 어려움도 있다. 하지만 계약까지의 일이다.
 
♾️ 용역수행단계
: 관리상 문제가 항시 있다. 특히 공정과 품질에 대한 이슈는 하나씩 해결해 가야 한다. 잘 진행되고 있는 업무도 이해 부족에 따른 예외 사항을 발견할 수 있으며 이는 의사소통의 폭을 넓혀 소통해야 한다. 예기치 않은 요구사항이 잦아질 수도 있고 뜻하지 않은 인력 변경이 발생하기도 한다. 이런 과정들이 가시성을 확보하기가 쉽지 않아 추가적인 비용 발생에 따른 껄끄러운 상황이 생길 수 있다.
 
♾️ 인수인계단계
: 용역수행의 결과이다. 납품되는 최종산출물에 대한 품질 문제가 실제 인도 단계에서 발생하는 경우도 많다. 이런 사항들은 납기를 못 맞추는 아주 심각한 상황을 초래하며 초과 비용, 소유권 시비 및 불충실한 문서나 인수인계 문제도 많다. 서로의 입장만 내세우다 보면 어느 한쪽의 입장만을 고려할 수도 없다.
 
내 조직 내에서의 일도 힘들지만 이를 외주로 주면서 생기는 문제는 더 많이 생길 수밖에 없다. 하지만 그만큼 서로 신경을 쓰고 업무에 충실하게 임한다면 문제가 아닌 성과로, 더 나아진 모습으로 함께할 수 있는 관계로 발전할 수 있다. 여기엔 업체선정까지의 철저한 과정, 그리고 의사 소통라인의 강화 및 지속적 모니터링과 관리가 병행되어야 함은 당연하다.
 
 
 
 
※ 정규직 싫어요!
시장에 막 들어온 신입사원들을 빼고는 어느 정도 경력과 실력 있는 인력들이 회사를 그만두는 사례가 많아지고 있다. 이런 그들에게 이야기를 들어보면 최우선적으론 급여이고 두 번째는 자신의 조건에 맞는 일자리를 찾을 수 있다는 것이다. 하지만 프리랜서도 마냥 좋은 것만은 아니다. 지속적인 일거리를 스스로 만들어야 하며 시장에서 살아남기 위해선 끊임없이 공부하고 기술력을 계속 보강, 확대하여야 한다. 남이 대신 해주던 일을 스스로 해야 하는 1인 기업가로서 자리매김하지 않으면 사실 어디서 일하던 똑같을 수밖에 없다. 즉 직장인이 아닌 기업가가 되어야 한다.