실행 없는 계획은 헛되고, 계획 없는 실행은 치명적입니다. —작자 미상

3.1 착수와 프로젝트 생애 주기

물리학에 따르면 빛은 입자인 동시에 파동입니다. 프로젝트 관리도 이와 비슷하게 이중적인 성격을 지닙니다. 프로젝트 관리는 시작과 끝이 분명한 일련의 개별 단계인 동시에, 하나의 끝이 새로운 시작으로 이어지는 연속적이고 순환적인 과정입니다. 성공적인 프로젝트 관리자는 프로젝트 전반에 걸쳐, 변화하는 상황이 발생할 때마다 그저 대응하기보다는 이를 미리 예측하려고 노력합니다.

먼저 좀 더 전통적인 관점부터 살펴봅시다. 이 관점에서는 프로젝트 관리를 일련의 순차적 단계로 설명하며, 프로젝트 착수는 프로젝트 선정 바로 다음에 옵니다. 그림 3-1에 나타난 이러한 단계들은 프로젝트 관리의 입자적 성격으로 생각할 수 있습니다.

그러나 프로젝트 착수는 프로젝트의 공식적인 시작을 알리는 것이지만, 착수를 잘하려면 만드는 단계 너머로 프로젝트 최종 결과물의 전체 생애 주기까지 내다보아야 합니다. 이것은 프로젝트 관리의 파동적 성격으로 생각할 수 있습니다. 그림 3-2에서 보듯이, 프로젝트가 착수되고 실행되는 만드는 단계는 더 큰 순환의 한 부분이며, 이 순환에는 고객이 프로젝트를 활용하는 운영/사용/변경 단계와, 프로젝트가 더 새롭고 나은 것으로 대체될 수 있도록 폐기되는 철거 단계가 포함됩니다.

이처럼 생애 주기 전체를 아우르는 총체적인 관점을 취하면, 프로젝트에서 "성공"이 진정 무엇을 의미하는지에 관해 더 나은 질문을 던지게 됩니다. 예를 들어, 지속 가능성이 엔지니어링에서 늘 고려해야 하는 관심사가 되면서, 프로젝트 관리자는 프로젝트의 성공을 판단할 때 장기적인 환경 영향을 함께 고려해야 하는 경우가 많습니다. 이를 위해서는 "제품, 재료, 공정 또는 활동이 환경에 미칠 수 있는 잠재적 영향"을 평가하고 "재료 획득부터 제조, 사용, 최종 처분에 이르기까지 제품 시스템의 전체 생애 주기에 걸친 다양한 환경 영향을 평가"하는 전과정 평가(LCA)와 같은 도구를 사용해야 합니다(United States Environmental Protection Agency n.d.).

착수 단계 초기에 LCA 분석을 수행하면 프로젝트가 미칠 수 있는 잠재적 영향을 더 넓게 바라볼 수 있고, 프로젝트를 시작하면서 검토하는 선택지의 폭도 넓힐 수 있습니다. 건설 산업에서 LCA는 흔히 건물의 생애 주기 동안 사용되는 에너지와 물에 초점을 맞춥니다. 제품 개발에서 LCA는 무엇보다도 원자재 가공, 생산, 포장, 재활용이 미치는 영향을 평가하는 데 사용됩니다. 의류 산업 분석의 흥미로운 사례로 다음 자료를 참고하십시오: "청바지의 생애 주기."

LCA는 프로젝트 전반에 걸쳐 전개되는 지식 습득 과정을 시작하는 여러 방법 가운데 하나일 뿐입니다. 프로젝트를 시작할 때 프로젝트에 대해 거의 또는 전혀 알지 못하는 것은 드문 일이 아닙니다. 프로젝트를 마칠 무렵이면 처음에 알았으면 좋았을 모든 것을 알게 되고, 새로운 프로젝트로 가져갈 수 있는 지식도 얻게 됩니다. 프로젝트에 대해 배우는 것은 무엇이든 중요하지만, 착수 단계에서 수집한 정보는 프로젝트가 전개되면서 필연적으로 생겨날 살아 있는 질서의 불확실성에 대응할 수 있는 기반이 됩니다. 이 정보는 착수 단계 너머로 프로젝트의 전체 생애 주기를 내다보게 하고, 이어서 새로 얻은 지식을 바탕으로 다시 돌아와 프로젝트 착수에 더 총체적으로 접근하도록 이끌 수 있습니다.

프로젝트에 대해 배우는 가장 좋은 방법 가운데 하나는 관련된 모든 사람과 이야기하는 것입니다:

이러한 대화와 요구 분석을 우선순위에 두면 프로젝트의 전체 생애 주기를 더 넓게 바라볼 수 있습니다. 물론 프로젝트를 일상적으로 운영하면서 매 순간 앞을 내다보는 데만 시간을 쓸 수는 없으며, 일정과 인력 같은 세부 사항에 집중하면서 프로젝트 관리의 전통적인 단계에 주의를 기울여야 합니다. 그렇더라도 한 단계와 관련된 작업을 완료하면서 다음 단계와 관련된 작업을 미리 생각해야 하는 경우가 많습니다. 그림 3-3에서 볼 수 있듯이 여러 단계가 상당 부분 겹치는 것은 흔한 일입니다. 프로젝트에 대해 더 많이 알게 되면서 착수 단계에서 수집한 정보를 되돌아보고 수정해야 하는 경우가 많을 것입니다.

프로젝트는 학습을 통해 지식을 얻는 활동이라는 점을 기억하십시오. 대부분의 경우, 프로젝트 착수 단계에서 알고 있는 것은 프로젝트가 끝났을 때 알게 될 것의 극히 일부에 불과합니다. 프로젝트에 대해 더 많이 알게 될수록 그에 맞춰 적응할 준비가 되어 있어야 합니다.

3.2 착수 단계의 작업

착수 단계에서는 일반적으로 프로젝트를 높은 수준에서 조망하는 다음 항목들의 초안을 작성합니다:

• 프로젝트 헌장: 프로젝트 착수와 계획을 위한 "단일하고 통합된 정보 출처"(Richter 2014)입니다. 프로젝트 헌장은 프로젝트에 대한 현재의 지식을 기술하며, 모든 이해관계자의 이름, 조직의 요구 사항 기술서, 프로젝트에 이르기까지의 경위, 프로젝트의 목적, 산출물, 역할과 책임 같은 정보를 담습니다. 프로젝트 헌장은 프로젝트 개요 기술서라고 불리기도 합니다. 프로젝트 헌장을 프로젝트 팀과 프로젝트 후원자 사이의 계약으로 생각하면 도움이 될 수 있습니다.
• 범위 기술서: 프로젝트의 범위를 정의하는 문서입니다. 범위 정의는 사실상 착수 단계의 핵심이며, 다음 절에서 자세히 다룹니다.
• 비즈니스 케이스: "의사 결정자가 어떤 조치를 승인하도록 설득하기 위한, 대개 문서로 작성된 논거입니다. 원칙적으로 비즈니스 케이스는 매력적인 투자 수익률(ROI)에 이르는 명확한 경로를 제시해야 합니다. 가장 단순한 형태의 비즈니스 케이스는 구두 제안일 수도 있습니다…. 더 복잡한 사안의 경우, 비즈니스 케이스는 신중하게 구성된 문서로 제시되어야 합니다. 비즈니스 케이스 문서는 조치를 취하는 경우와 반대로 조치를 취하지 않는 경우 모두에 수반되는 이점과 위험을 검토해야 합니다. 결론은 실행을 뒷받침하는 설득력 있는 논거여야 합니다"(TechTarget n.d.). 비즈니스 케이스는 다음과 같은 근본적인 질문에 답합니다: 1) 왜 이 프로젝트인가? 2) 왜 다른 프로젝트가 아닌 이 프로젝트인가? 3) 왜 지금 이 프로젝트인가?

프로젝트 헌장과 범위 기술서는 모두 일반적으로 프로젝트가 진행되고 계획 단계에서 프로젝트의 세부 사항을 더 많이 알게 됨에 따라 발전합니다. 따라서 착수 단계를 진행하는 동안에는 계획 단계의 다음 요소들을 항상 미리 염두에 두어야 합니다:

• 작업분류체계(WBS): 프로젝트 산출물과 관련된 작업들을 기술한 것으로, 흔히 트리 다이어그램 형태로 작성됩니다. 작업분류체계는 "각 작업이 다른 작업들, 전체, 그리고 최종 산출물(목표 또는 목적)과 맺는 관계를 보여줍니다. 또한 책임의 할당을 보여주고, 프로젝트의 모니터링과 관리를 위해 각 단계에서 필요한 자원과 가용 시간을 파악합니다"(Business Dictionary n.d.). 작업분류체계 템플릿이 담긴 Excel 파일은 여기에서 내려받을 수 있습니다: 작업분류체계(WBS) 템플릿
• 조직분류체계(OBS): 프로젝트 팀을 기술한 것입니다. 조직분류체계는 "누가 누구에게 보고하는지, 위계의 세부 사항, 그리고 보고 체계를 설명합니다…. 조직분류체계는 일반적으로 그래프나 차트를 사용하여 시각적으로 전달됩니다. 프로젝트 관리자나 총괄 관리자를 명시하고, 그 PM 아래에 제품 개발, 설계, 자재 관리, 생산과 같은 여러 부서를 둘 수 있습니다"(Bradley n.d.). 아래의 책임 할당 매트릭스(RAM)도 참조하십시오.
• 작업 패키지(work package): “프로젝트 내 관련 작업들의 묶음입니다. 작업 패키지는 그 자체로 프로젝트처럼 보이기 때문에, 더 큰 프로젝트 안의 하위 프로젝트로 여겨지는 경우가 많습니다. 작업 패키지는 작업분류체계(WBS)를 만들 때 프로젝트를 나눌 수 있는 가장 작은 작업 단위입니다”(Wrike n.d.).
• 책임 할당 매트릭스(RAM): 조직분류체계의 한 유형으로, 격자 형태를 띠며 일반적으로 첫 번째 열에는 프로젝트 작업을, 맨 위 행에는 이해관계자를 나열하고 각 작업을 여러 이해관계자에게 할당합니다. 이를 활용하면 프로젝트에 필요한 자원이 충분한지 판단하고, 누가 무엇을 책임지는지 기록할 수 있습니다. RAM에는 여러 형태가 있지만, 가장 유용한 것 중 하나는 RACI(responsible, accountable, consult, inform) 차트로, 다음 범주를 사용하여 각 작업에 대한 각 이해관계자의 관계를 지정합니다. 실행 책임(실제로 작업을 수행함), 최종 책임(해당 활동에 대한 최종 권한을 가짐), 협의(해당 활동에 관한 정보를 제공할 수 있음), 통보(활동이 완료된 후 통보받음. 대개 자신의 작업이 그 활동에 의존하기 때문임)(Doglione 2018). RACI 매트릭스 템플릿은 다음에서 내려받을 수 있습니다: “Responsibility Assignment Matrix(책임 할당 매트릭스).” RACI 차트에 대한 간략한 소개는 다음 웹 페이지를 참조하십시오: “RACI Charts(RACI 차트).” (RACI 차트는 선형 책임 차트라고도 합니다.)

3.3 성공 정의하기

경험 많은 프로젝트 관리자는 프로젝트에서 “성공”이 무엇을 의미하는지 정의하고 이를 어떻게 측정할지 정하는 것으로 신속하게 시작해야 한다는 것을 알고 있습니다. 이를 위해서는 프로젝트의 성공 여부를 판단할 개인 및 조직과 이야기를 나누어야 합니다. 여기에는 내부 또는 외부 고객, 승인 권한을 가진 개인이나 그룹, 또는 잠재 고객 집단이 포함될 수 있습니다. 많은 프로젝트가 난관에 빠지는 것은 담당 엔지니어들이 "우리는 목표를 달성했습니다. 계획서에 적힌 대로 따랐습니다”라고 말하지만 고객은 “내가 원하던 것을 제공하지 않았습니다”라고 말할 때, 많은 프로젝트가 난항을 겪습니다.

사양이 고객의 요구와 맞지 않아 출시된 후 단종된 제품은 셀 수 없이 많습니다. 한 가지 예는 2013년에 출시된 페이스북 홈(Facebook Home)으로, 이는 안드로이드 휴대폰용 사용자 인터페이스였는데 페이스북을 사용자의 홈 화면으로 바꾸면서 독(dock)이나 앱 폴더처럼 안드로이드 사용자들이 아끼는 기능을 없애 버렸습니다. 어떻게 회사가 이렇게 큰 실수를 저지를 수 있었을까요? Business Insider에 따르면, 주로 아이폰 사용자들로 구성된 페이스북 홈 개발 팀은 "일반적인 안드로이드 사용자가 익숙해져 있을 법한 기능, 그리고 페이스북 홈을 설치할 때 잃고 싶지 않을 법한 기능을 잘 알지 못했습니다"(Carlson 2013). 이처럼 고객의 요구를 파악하지 못한 결과는 처참했습니다. 페이스북 홈이 사전 설치되어 출시된 휴대폰인 HTC 퍼스트(HTC First)의 가격은 몇 주 만에 99달러에서 99센트로 떨어졌습니다(Tate 2013). 결국 타임(Time)지는 HTC 퍼스트를 2013년 “기술 분야에서 가장 형편없었던 순간” 중 하나로 선정했습니다(McCracken 2013).

의료기기 산업에서는 개발 팀이 FDA 인증을 받는 데 따르는 장애물을 과소평가하면, 성공적으로 개발된 제품이라도 결국 실패로 여겨질 수 있습니다. 또한 자율주행차를 보면 성공이 제품 완성이라는 좁은 범위를 넘어선다는 것을 알 수 있습니다. 자율주행차는 이미 존재하지만, 성공적인 프로젝트가 되려면 예측할 수 없는 인간 운전자와 성공적으로 상호작용할 수 있어야 하고 정부의 승인도 받아야 합니다.

자본 프로젝트에서 총소유비용(건물의 건설 및 사용과 관련된 직접 비용과 간접 비용의 총합)은 건물의 성공 여부를 판단하는 데 매우 중요합니다. 예를 들어, 올림픽 기간에만 사용하도록 설계된 건물이 결국 그 후로도 수년간 사용된다면 건물의 유지 관리 비용은 기하급수적으로 증가할 가능성이 높으며, 개최 도시의 관점에서 볼 때 성공적이라고 여겨졌던 건물이 장기적으로는 실패작으로 바뀌게 됩니다. 핵심은 건물의 총 설계 수명을 현실적으로 예측하는 것입니다. 유지 관리 비용은 기부자의 자금으로 진행된 건설을 성공으로 볼 수 있는지의 문제에도 영향을 미칩니다. 이러한 경우 성공은 사실상 운영 자금이 완전히 확보된 인프라로 정의되어야 함에도 불구하고, 흔히 시설의 '개관'으로 정의됩니다.

성공적인 프로젝트 관리자는 일반적으로 프로젝트 성공을 정의할 때 매우 구체적입니다. 반면 신임 프로젝트 관리자는 지나치게 포괄적으로 정의하는 실수를 범합니다. 그러나 구체적이라는 것이 반드시 장황하다는 의미는 아닙니다. 물리적 요구 사항의 방대한 목록을 만드는 데 집중하기보다 최종 사용자의 요구에 집중하면, 프로젝트에 대한 간결하고 유용한 '성공'의 정의를 제시할 수 있습니다. 9·11 테러 이후 펜타곤 재건 프로젝트의 관리자였던 리 에비(Lee Evey)는 이러한 접근 방식을 취하여 수천 페이지에 달하는 사양서를 "16개의 성능 기반 요구 사항으로 통합할 수 있었습니다. 예를 들어, 그의 에너지 효율 요구 사항은 건물의 냉난방에 연간 특정 BTU[영국 열량 단위] 이상을 사용하지 않아야 한다는 것이었습니다. 그다음 예산 범위 내에서 그 요구 사항을 충족하는 것은 설계·시공 팀의 몫이었습니다"(Rife 2005).

3.4 프로젝트 헌장 작성

프로젝트 헌장을 작성하는 것은 프로젝트 착수에서 가장 중요한 부분 중 하나입니다. 프로젝트 헌장을 작성하는 과정에 모든 핵심 이해관계자를 참여시키면, 무엇이 프로젝트 성공인지, 관련 제약 조건(예: 시간과 예산), 그리고 범위의 정의에 대한 합의를 확보하는 데 도움이 됩니다.

프로젝트 헌장의 정확한 형식은 조직마다 다릅니다. 어떤 회사에서는 프로젝트 헌장이 스프레드시트 파일이고, 다른 회사에서는 문서 파일입니다. 웹에서 프로젝트 헌장 템플릿을 많이 찾을 수 있습니다. Managing Projects Large and Small: The Fundamental Skills for Delivering on Budget and on Time(대규모 및 소규모 프로젝트 관리: 예산과 일정을 지키며 결과를 내기 위한 기본 기술), 에 따르면, 일반적인 프로젝트 헌장에는 다음 항목의 일부 또는 전부가 포함됩니다.

무엇보다도 프로젝트 헌장은 프로젝트의 목표, 곧 성공의 정의를 명확하고 구체적으로 밝혀야 합니다. 목표는 측정 가능해야 하며, 그래야 프로젝트의 성공 여부를 두고 혼란이 생기지 않습니다.

그러나 프로젝트 목표는 구체적으로 밝히되, 그 목표를 어떻게 달성할지에 관한 세부 사항에 얽매이지 않도록 주의하십시오.

3.5 프로젝트 범위 관리

시간, 비용, 범위는 프로젝트 관리의 삼중 제약으로 알려져 있습니다. 이 중 하나를 바꾸면 나머지 중 적어도 하나도 바뀔 수밖에 없습니다. 프로젝트를 완료하는 데 예상보다 두 배의 시간이 걸린다면 비용은 거의 확실히 늘어날 것입니다. 반대로, 예를 들어 경험이 적은 인력을 투입하여 비용을 줄이기로 결정하면 작업 속도가 느려져 일정이 늘어날 수 있습니다. 이러한 결정은 품질이 낮은 제품이라는 형태로 프로젝트 범위의 변경을 초래할 수도 있습니다.

착수 단계는 시간과 비용에 관한 세부 사항을 정확히 확정하기에는 너무 이른 시점이지만, 범위, 즉 "프로젝트가 제공하는 제품이나 서비스를 내놓기 위해 수행해야 하는 모든 작업"(Martinez n.d.)에 대해 오랫동안 깊이 생각해 보기에는 좋은 시기입니다. 이 초기 단계에서 여러분과 프로젝트 이해관계자들은 시간, 비용, 범위의 제약에 구애받지 않고 프로젝트가 이룰 수 있는 것에 대해 자유로운 발상을 해 볼 수 있습니다. 그러나 머지않아 현재 확보한 정보를 활용하여 프로젝트 범위의 정의를 확정하고, 이를 범위 기술서로 공식화해야 합니다.

아주 단순한 프로젝트를 제외하면, 어떠한 범위 정의든 프로젝트와 고객의 요구에 대해 더 많이 알아 갈수록 거의 확실히 진화하게 됩니다. 범위 진화라는 용어는 모든 이해관계자가 동의하고, 그에 상응하는 예산 및 일정 변경이 수반되는 변경을 가리킵니다. 범위 진화는 프로젝트가 전개되면서 이루어지는 학습의 자연스러운 결과입니다. 예를 들어 최종 사용자의 요구에 대한 새로운 통찰, 새로운 규제, 시장의 격변 등에서 비롯되는 학습이 이에 해당합니다. 모든 이해관계자가 범위 변경(그리고 이에 따른 예산 및 일정 변경)에 동의하는 한, 범위 진화는 고객이 프로젝트에서 실제로 원하는 것을 얻도록 보장합니다. 고객과 더 많이 대화하고 그들의 요구에 대해 더 많이 알수록 범위를 더 정교하게 다듬을 수 있습니다.

실제로 프로젝트 관리자의 주요 업무 중 하나는 범위 진화를 관리하는 것입니다. 그러나 프로젝트의 유형에 따라 범위 진화의 정도는 다양합니다. 예를 들어 특정 환경 규제를 충족하는 것과 관련된 프로젝트를 진행하고 있다면, 규제 자체가 바뀌지 않는 한 프로젝트 범위의 초기 정의가 명확하여 프로젝트가 전개되는 동안 다듬을 부분이 거의 없을 수 있습니다. 그러나 완전히 새로운 시장 수요를 충족하도록 설계된 제품을 개발하고 있다면, 고객의 요구를 충족하기 위해 범위를 지속적으로 다듬어야 할 수도 있습니다.

범위 진화의 가장 흔한 원인은 아마도 프로젝트가 계획되고 실행되는 맥락의 변화일 것입니다. 시장 요인의 변화, 인구 구성의 변화, 새롭거나 더 치열해진 경쟁, 기술 발전은 모두 프로젝트의 맥락을 바꾸어 범위를 재고하게 만들 수 있습니다. 이처럼 맥락이 변할 가능성이 있다는 것은 똑같은 프로젝트란 없다는 뜻입니다. 프로젝트 B가 프로젝트 A와 거의 같다고 생각할 수도 있지만, 갑작스러운 맥락의 변화가 모든 것을 바꿀 수 있습니다. 그림 3-4에서 보듯이, 맥락은 대체로 프로젝트가 이루어지는 조직적, 사회적, 정치적 구조에 의해 규정됩니다.

범위 진화의 가능성에는 열린 태도를 유지해야 하지만, 범위 크리프, 즉 그에 상응하는 예산 및 일정의 승인된 변경 없이 범위가 통제되지 않은 채 연쇄적으로 변경되는 현상에는 반드시 맞서야 합니다. 둘의 차이는 관리되는 변경과 관리되지 않는 변경의 차이입니다.

• 범위 진화는 관리된 변경입니다. 이는 프로젝트 참여자들이 프로젝트에 대해 더 많이 알게 되면서 발생하는, 승인된 프로젝트 범위 변경입니다. 범위 진화는 모든 프로젝트 참여자의 합의에 따라 프로젝트 범위를 공식적으로 변경하며, 그에 따라 프로젝트 예산이나 일정도 변경됩니다. 이러한 관리된 변경은 프로젝트 전 과정에서 이루어지는 학습에서 비롯되는 자연스럽고 합리적인 결과입니다. 이는 의도한 프로젝트 가치를 달성하기 위해 새로운 정보로 인해 프로젝트의 핵심 요소를 재검토해야 할 때 이루어지는 의식적인 선택입니다.
• 범위 크리프(scope creep)는 관리되지 않은 변경입니다. 이는 프로젝트 범위에 대한 통제되지 않은 변경으로 인해 발생합니다. 이러한 변경은 고객 관점에서는 가치를 더할 수도 있지만, 범위 변경에 소모되는 시간, 비용, 자원 때문에 추가적인 초과가 발생합니다. 범위 크리프는 아무도 프로젝트 범위에 세심한 주의를 기울이지 않기 때문에 조금씩 발생하는 경향이 있습니다. 예를 들어 조리대와 수납장을 교체하기 위한 주방 리모델링 프로젝트에서 마지막 순간에 모든 가전제품을 교체하기로 결정하는 것은 범위 크리프의 한 예라고 할 수 있습니다.

명확한 범위 기술서 작성하기

범위 관리의 핵심은 명확하고 정밀하게 공들여 작성한 범위 기술서입니다. 프로젝트를 어떻게 수행할지에 대한 세부 사항은 처음에는 모호할 수 있지만, 달성하고자 하는 것은 완벽하게 명확해야 합니다. 모호함은 프로젝트 범위에 작은 변경을 일으킬 수 있고, 이는 다시 다른 변경으로 이어지며, 이러한 과정이 반복되어 결국 원래 프로젝트를 더 이상 알아볼 수 없게 됩니다.

프로젝트 범위를 정의하는 문서인 범위 기술서를 작성하는 일은 착수 단계의 주요 부분입니다. 그러나 브래드 비글로(Brad Bigelow)가 PMI(Project Management Institute)에 기고한 글에 따르면, 범위 기술서는 “대개 해석과 오해의 여지를 남기는 정성적인 용어로 표현됩니다. 그 결과, 범위 기술서는 프로젝트에서 갈등의 가장 큰 원인이 되는 경우가 많습니다”(2012, 1).

이러한 문제를 피하기 위해 숙련된 프로젝트 관리자는 프로젝트에 무엇을 포함해야 하고 무엇을 포함하지 말아야 하는지 파악하는 데 많은 노력을 기울인 다음, 그 경계를 범위 기술서의 형태로 최대한 명확하게 표현합니다. 비글로에 따르면 이 작업은 프로젝트의 성공을 보장하는 데 필수적입니다. “인간이 관여하는 한, 어떤 프로젝트의 범위도 모호함, 즉 주관성과 불완전한 정의에서 완전히 자유로울 수는 없습니다. 반면에 범위가 완전히 모호하고, 정의되지 않았으며, 예측할 수 없는 기대에 좌우된다면 어떤 프로젝트도 착수 단계를 넘기기는 매우 어렵습니다”(2).

범위가 제대로 정의되지 않으면, 무엇이 프로젝트 범위에 포함되고 무엇이 포함되지 않는지는 관점의 문제로 전락합니다. 당연하게도 이러한 “서로 다른 관점은… 종종 프로젝트 내 갈등의 근원이 될 수 있습니다”(2). 비글로는 팀과 고객이 사안을 매우 다르게 바라보는 프로젝트를 다음과 같이 설명합니다.

범위가 제대로 정의되지 않으면 고객을 만족시키기가 점점 더 어려워질 수 있으며, 팀은 고객이 원한다고 생각하는 것을 열심히 만들어 내고 나서야 “아니요, 그게 아닙니다.”라는 말을 듣게 됩니다.

범위 기술서에 정확히 무엇을 포함해야 하는지에 대해서는 의견이 다양하지만, 최소한 다음 내용은 포함해야 합니다.

• 프로젝트가 해결할 비즈니스 요구 사항의 요약을 포함한, 프로젝트 목적에 대한 간략한 근거.
• 프로젝트 목표에 대한 설명.
• 인수 기준: 고객이 산출물을 인수하기 전에 제품이나 서비스가 충족해야 하는 조건을 명시합니다.
• 산출물: "프로젝트 완료 시 제공될 정량화 가능한 재화 또는 서비스입니다. 산출물은 개발 과정의 유형적 또는 무형적 부분일 수 있으며, 흔히 프로젝트의 특정 기능이나 특성으로 명시됩니다"(Investopedia n.d.).
• 프로젝트에서 제외되는 모든 것에 대한 설명, 다시 말해 프로젝트 범위에 포함되지 않는 것에 대한 설명. 이 목록은 "모든 이해관계자에게 프로젝트의 경계를 정의하는 데 필요한 만큼 상세해야" 합니다(Feldsher 2016).
• 예산 및 일정과 같은 제약 조건.
• 프로젝트에 대해 현재 사실이라고 믿는 모든 것을 포함한 가정 사항. "프로젝트를 구상하고, 계획하고, 수행하는 과정에서 불확실한 정보를 어떻게 다룰 것인지에 대한" 아이디어를 포함하는 것도 도움이 됩니다(Portny n.d.).
• 프로젝트 전반에 걸쳐 사용할 계획인 새롭거나 특이한 기술에 대한 설명. 이는 범위 기술서의 일반적인 구성 요소는 아니지만, "이해관계자들이 그 투명성을 높이 평가하고 프로젝트가 진행되는 것을 더 편안하게 받아들일 가능성이 높습니다"(Feldsher 2016).

범위를 다루기 위한 몇 가지 실용적인 아이디어

성공적인 프로젝트 관리자는 고객을 이끄는 데 능숙합니다. 고객은 무언가를 직접 보기 전까지는 자신이 무엇을 원하는지 모를 수도 있기 때문입니다. 진정으로 혁신적인 제품의 경우, 고객은 자신이 원하는 것을 정의하지조차 못할 수도 있습니다. 헨리 포드가 했다고 알려진 격언이 이를 깔끔하게 요약합니다. "사람들에게 무엇을 원하는지 물었다면, 그들은 더 빠른 말이라고 답했을 것입니다." 소니 워크맨은 휴대용 음악에 대해 확인된 소비자 수요를 충족하기 위해 만들어진 것이 아니라, 오페라를 편리하게 들을 방법을 찾던 소니 공동 창업자 이부카 마사루의 요청에 따라 만들어졌습니다. 한 소니 디자이너가 이 특별한 요청에 착수했고, 그 결과물은 소니 역사상 가장 성공적인 제품 중 하나가 되었습니다(Franzen 2014).

페이스북의 개발자들은 페이스북 홈을 출시할 때, 소니가 고객들을 새로운 음악 감상 방식으로 이끌었던 것처럼 자신들도 고객들을 새로운 휴대전화 사용 방식으로 이끌고 있다고 생각했습니다. 그러나 페이스북 개발자들은 안드로이드를 사용하는 고객들의 요구를 너무나 몰랐기 때문에 결국 쓸모없는 제품을 만들고 말았습니다. 이 이야기의 교훈은 고객을 이끌려고 시도하기 전에 고객의 요구를 반드시 이해해야 한다는 것입니다.

범위에 대해 생각할 때 염두에 두어야 할 몇 가지 다른 팁은 다음과 같습니다.

• 엔지니어는 자신이 아는 것에 지나치게 집중하고, 자신이 모르는 것에는 별로 관심을 두지 않는 경향이 있습니다. 시간을 들여 자신이 모른다는 것을 알고 있는 것이 무엇인지 생각해 보십시오. 그런 다음 그러한 미지의 요소가 수반할 수 있는 잠재적 위험에 어떻게 대처할지 상상해 보십시오.
• 엔지니어는 매우 세부 지향적인 사람인 경향이 있습니다. 이러한 성향 때문에 큰 그림은 고려하지 않은 채 프로젝트의 모든 세부 사항을 하나하나 계획하게 된다면, 프로젝트 착수 단계에서 문제가 될 수 있습니다. 물론 세부 사항도 중요하지만, 초기에는 높은 수준의 관점도 가져야 합니다. 모든 세부 사항이 똑같이 중요한 것은 아니며, 중요한 세부 사항도 시간이 지남에 따라 달라질 수 있습니다.
• 엔지니어는 생각하기보다 실행하는 데 집중하는 경향이 있습니다. 그들은 곧바로 뛰어들어 프로젝트를 실행하기 시작하는 것을 좋아합니다. 그러나 프로젝트 착수 단계는 먼저 생각하는 시간이라는 점을 기억하십시오. 특히 범위 정의는 자신이 모르는 것을 개념화하려고 시도하는 사고 과정입니다.
• 모든 프로젝트 요구 사항이 동등한 것은 아닙니다. 요구 사항은 "반드시 있어야 하는 것"부터 "있으면 좋은 것"까지 다양할 수 있습니다. 고객과 요구 사항을 논의할 때는 각 요구 사항이 이 척도에서 어디에 해당하는지 반드시 파악하십시오.
• 프로젝트에 관해 고객에게 가능한 한 다양한 질문을 하십시오. "고객의 요구 사항과 기대를 가능한 한 많은 각도에서 탐색함으로써 프로젝트 팀은 프로젝트 범위의 불확실한 요소의 수를 크게 줄이고 이러한 요소의 잠재적 변동성을 줄일 수 있습니다. 이것이 프로젝트 범위를 둘러싼 갈등이 발생하지 않으리라고 보장하지는 않지만, 이러한 갈등의 잠재적 원인을 분리해 내는 데 도움이 될 수 있습니다"(Bigelow 2012, 4).
• 최고의 프로젝트 관리자는 고객이 "가치"와 "성공"을 어떻게 정의하는지 최대한 많이 알아내는 것이 중요하다는 점을 이해하며, 그런 다음 고객이 상상할 수 있는 범위를 넘어서는 방식으로 그 목표를 달성할 방법을 제안합니다. 이러한 프로젝트 관리자는 성능 요구 사항과 이를 달성하기 위한 선택지에 집중하며, 너무 성급하게 한 가지 접근 방식에 얽매이는 것을 피합니다.
• 프로젝트가 착수 단계를 지나 계획 및 실행 단계로 진행되면, 프로젝트의 범위 정의를 정기적으로 검토하여 여전히 적절한지 확인하는 것을 잊지 마십시오. 프로젝트가 진행되고 이해관계자가 프로젝트에 대해 더 많이 알게 되면서 범위 변경은 대개 불가피합니다. "실제로 프로젝트가 범위 변경을 수용하지 못하면, 그 변경을 받아들였을 때보다 조직 전체에 훨씬 더 심각한 결과를 초래할 수 있습니다. 설령 그 변경으로 프로젝트의 예산이 늘어나고 일정이 연장되었더라도 마찬가지입니다. 프로젝트가 그러한 변경에 적응하는 능력은 조직에 대한 프로젝트의 궁극적인 가치에 결정적인 차이를 만들 수 있습니다. 결국 프로젝트의 목표는 조직의 목표에 종속되는 것이지, 그 반대가 아닙니다. 따라서 프로젝트 팀은 프로젝트를 시작하는 바로 그 시점에 무엇이 더 중요한지 이해하는 것이 매우 중요합니다. 변경을 피하는 것입니까, 아니면 변경을 관리하는 것입니까?"(Bigelow 2012, 6).
• 한 가지 위험은 시장에 있는 모든 경쟁 제품의 가장 좋은 기능을 전부 갖춘 제품을 명세하는 것입니다. 예를 들어 출시 시점에 가능한 한 가장 작은 설치 면적, 가장 높은 효율, 가장 낮은 비용, 가장 높은 토크, 그리고 구할 수 있는 모든 부속품을 갖춘 산업용 모터를 설계하는 경우입니다. 단순히 사양 면에서 경쟁 제품을 능가하려고만 하면 팀이 획기적인 해결책을 모색하지 못하게 됩니다.
• 프로젝트 범위를 성공적으로 정의하는 팀은 대개 고객이 관련 제품이나 서비스를 사용하는 모습을 관찰하는 데 시간을 들이는 것으로 시작합니다.

3.6 현장의 목소리: 지속 가능성과 적응적 과제에 대한 Michael Mucha의 이야기

마이클 무카(Michael Mucha)는 매디슨 광역 하수도 지구(Madison Metropolitan Sewerage District)의 수석 엔지니어 겸 디렉터이며, 현재 ASCE 지속 가능성 위원회의 위원장을 맡고 있고, 위스콘신주 매디슨의 Sustain Dane 이사회 이사로도 활동하고 있습니다. 그는 프로젝트의 범위가 해결하려는 문제의 종류에 따라 결정된다고 설명합니다. 그 문제가 기술적인 것으로, 엔지니어가 전통적으로 제공하도록 훈련받은 명확한 해결책이 있습니까? 아니면 적응적인 것으로, 어떻게 진행해야 할지에 대한 확실한 합의가 없고 어떤 해결책이든 이해관계자의 가치관과 신념에 도전하게 될 것이 분명합니까? 아니면 둘이 섞인 것입니까?

지속 가능한 엔지니어링 해결책에는 적응적 과제가 수반되는 경우가 많습니다. 그 예로, 그는 최근 프로젝트를 다음과 같이 설명합니다.

적응적 문제와 기술적 문제의 구분은 로널드 A. 하이페츠(Ronald A. Heifetz)가 1998년 저서 Leadership Without Answers에서 처음으로 제시했습니다. 이 주제에 대한 실용적이고 실전적인 입문서로 무카는 The Practice of Adaptive Leadership (Heifetz, Linsky and Grashow 2009)를 추천합니다.

3.7 프로젝트 맥락

Merriam-Webster에 따르면, 맥락이라는 용어는 "어떤 일이 일어나는 상황, 즉 어떤 일이 일어나는 장소와 시점에 존재하는 조건들의 집합"을 가리킵니다. 모든 프로젝트는 여러 맥락 안에서 진행됩니다. 즉, 조직적 맥락(여러분의 조직과 고객의 조직 모두), 시장 맥락, 기술적 맥락, 사회적 맥락 안에서 진행됩니다. 이 모든 맥락은 프로젝트 수명 동안 변할 수 있으며, 현대 비즈니스 세계의 끝없는 급류 속에서는 아마 실제로 변할 것입니다. 훌륭한 프로젝트 관리자는 변화하는 맥락에 주의를 기울입니다. 그들은 맥락이 바뀌면 프로젝트도 아마 조정해야 할 것임을 알고 있습니다. 원래 목표가 더 이상 조직의 맥락에 맞지 않는 것으로 드러난다면, 원래 목표대로 프로젝트를 완료하는 것은 결국 끔찍한 결과가 될 수 있습니다.

맥락은 변할 수 있으므로 똑같은 프로젝트는 하나도 없습니다. 최근에 동일한 프로젝트를 완료했다고 생각하더라도, 맥락의 차이 때문에 어떤 식으로든 접근 방식을 바꿔야 한다는 사실을 거의 틀림없이 깨닫게 될 것입니다. 예를 들어, 디트로이트에서 병원을 성공적으로 지었다고 해서 샌프란시스코에서 병원을 짓는 일에 완벽히 대비할 수 있는 것은 아닙니다. 샌프란시스코는 지진 활동이 불안정한 지역이므로 내진과 관련된 수많은 문제를 고려해야 하기 때문입니다. 제품 개발에서는 고객이 처음에 자신의 요구를 완전히 이해하지 못했다는 사실을 알게 될 수도 있습니다. 고객이 원하는 바를 알아가기 시작하면서 프로젝트를 훨씬 더 넓고 복잡한 맥락에서 바라보게 될 수도 있습니다. 마찬가지로, 새로운 기술의 도입은 착수 단계에서 예상하지 못했던 방식으로 프로젝트의 복잡성을 높일 수 있습니다. 이러한 변화에 대처하려면 프로젝트가 전개됨에 따라 적응할 수 있는 유연한 프로젝트 팀에 의지할 수 있어야 합니다.

뉴욕 타임스에 실린 제임스 캔터(James Kanter)의 기사는 서로 “복제품”이 되도록 계획된 유럽의 원자력 발전소 두 곳의 건설 과정을 설명합니다. 두 발전소 모두 “카펫과 벽지”에 이르기까지 프로젝트의 모든 측면을 규정한 엄격한 표준에 따라 건설되었습니다. 프로젝트가 서로 유사하므로 두 곳 모두 순조롭게 진행될 것으로 예상되었지만, 예기치 못한 수많은 기술적 문제로 인해 큰 지연과 비용 초과가 발생했습니다. 이는 맥락이—원자로 하나는 핀란드에, 다른 하나는 프랑스에 있었습니다—동일하다고 여겨지는 프로젝트의 결과에 얼마나 극적인 영향을 미칠 수 있는지를 보여 주는 완벽한 사례입니다. 핀란드 현장의 문제로는 기초에 구멍이 너무 많아 부식되기 쉬웠던 점, 경험이 부족한 하도급업체가 엉뚱한 위치에 구멍을 뚫은 점, 그리고 8개의 서로 다른 언어를 사용하는 인력으로 구성되어 발생한 의사소통 문제 등이 있었습니다. 동일하다고 여겨졌던 프랑스 현장에서는 콘크리트 기초의 균열, 잘못 배치된 철근, 자격 미달의 용접공 등 또 다른 문제들이 있었습니다. 핀란드와 프랑스 프로젝트를 진행한 회사인 유니스타 뉴클리어 에너지(UniStar Nuclear Energy)에 따르면, 이와 유사한 원자로 다수가 전 세계에서 추진되고 있습니다. 그 프로젝트들에서 어떤 위험이 발생할지는 아무도 알 수 없습니다. 어쨌든 프랑스와 핀란드는 적어도 지질학적으로는 안정적인 곳입니다. 그러나 캔터가 지적하듯이, “중국이나 미국 같은 곳의 지진 위험, 심지어 폭풍 해일의 위협까지 고려하면 다른 지역에서 이러한 원자로를 건설하는 일은 훨씬 더 까다로울 것”입니다(2009).

맥락은 특히 제품 개발에서 중요합니다. 제품 개발에서는 신제품을 둘러싼 배경이 하룻밤 사이에 바뀔 수 있기 때문입니다. 제품 개발에 대해 더 유연한 접근 방식을 주장하는 논문에서 M. Meißner와 L. Blessing은 맥락이 제품 개발 프로세스에 영향을 미치는 다양한 방식을 논의합니다:

변화하는 맥락에서는 유연성이 핵심입니다. 성공적인 프로젝트 관리자들을 연구한 알렉산더 라우퍼(Alexander Laufer)는 최고의 프로젝트 관리자들이 다음과 같다는 사실을 발견했습니다.

라우퍼는 현대의 프로젝트 관리자들이 이전 세대보다 더 현대적이고 유연한 접근 방식을 사용해야 한다고 주장합니다:

5강에서는 상호 보완적인 기술을 갖춘 사람들, 이상적으로는 다양한 연령과 경험 수준을 가진 사람들을 한데 모으는 다양한 팀을 구성하는 것의 가치에 대해 이야기하겠습니다. 그렇다면 무엇보다 중요한 그 "풍부한 경험"이 부족한 신임 프로젝트 관리자는 어떻게 프로젝트의 여러 맥락에 대한 전반적인 이해를 넓힐 수 있겠습니까? 우선 비슷한 특성을 지닌 과거 프로젝트를 조사하고, 멘토와 상의하며, 전반적으로 이전 프로젝트에서 얻은 교훈에 관한 공식적·비공식적 자료를 가능한 한 많이 찾아 확인하는 것부터 시작하십시오. 조직, 고객, 업계, 그리고 세상 전반에 대해 늘 충분한 정보를 갖추고 있는 것도 도움이 됩니다. 예를 들어 지난 10년 동안 의료 분야에서 건설 프로젝트를 수행했다면, 의사 중심 체계에서 벗어나 환자가 스스로의 기준으로 가치를 정의할 수 있도록 힘을 실어 주려는 환자 중심 체계로 옮겨 가는 뚜렷한 맥락 변화를 경험했을 것입니다(Porter and Lee 2013). 그 분야에서 프로젝트 관리를 처음 맡았다면, 그러한 변화에 대해 배울 수 있는 것을 모두 배우는 것이 현명합니다. 살아 있는 질서에서는 거의 모든 업계에서 이처럼 지각을 뒤흔드는 변화가 예외가 아니라 일상입니다.

실용적인 팁

• 모든 이해관계자를 참여시키십시오: 여러분의 목표는 사람들이 프로젝트에 의미 있게 계속 참여하도록 하는 것입니다. 이해관계자들이 형식적으로 얼굴만 비추려고 프로젝트 회의에 나타나기를 바라지는 않을 것입니다. 그 대신 그들이 프로젝트 성공 가능성에 진지하게 집중하기를 바랄 것입니다.
• 결과의 명확성: 맨 처음부터 고객에게 성공을 정의해 달라고 요청하십시오. 그런 다음 고객 및 다른 이해관계자들과 함께 성공을 어떻게 측정할지 정의하십시오.
• 공통 어휘를 사용하십시오: 어떤 프로젝트든 시작할 때 최종 고객을 찾아가 그들의 어휘를 익히십시오. 그들에게 중요한 용어가 무엇이고 그 용어가 그들에게 어떤 의미인지 반드시 이해하십시오. 가능하면 언제나 여러분의 어휘가 아닌 고객의 어휘를 사용하십시오. 또한 가능할 때마다 쉬운 말로 이야기하도록 노력하고, 전문 기술 용어는 피하십시오.
• 용어집을 만드십시오: 복잡한 전문 용어가 많은 프로젝트에서는 용어집을 만드는 것을 고려하십시오. 그런 다음 모든 이해관계자가 접근할 수 있는 방식으로 공개하고, 필요에 따라 갱신하십시오. 다음은 그러한 용어집의 한 예입니다: "COSO 프레임워크."
• 모르는 것을 파악하십시오: 프로젝트를 시작할 때는 언제나 모르는 것이 있습니다. 핵심은 자신이 그것을 모른다는 사실을 아는 것입니다. 이를 인식하려고 노력할수록 그러한 미지의 요소를 더 잘 예측하고 대비할 수 있습니다.
• 핵심 팀원들이 주요 프로젝트 문서에 서명하게 하십시오: 연구에 따르면 문서에 서명하는 행위는 사람들이 그 문서에 기술된 약속을 이행하는 데 훨씬 더 전념하게 만듭니다. 프로젝트 팀 전체에게 프로젝트 헌장과 범위 문서에 서명해 달라고 요청하는 것을 고려하십시오. 이 간단한 행위가 프로젝트를 성공적으로 완수하게 하는 강력한 동기가 될 수 있습니다.
• 선제적 동시 진행: 초기 단계에서는 일을 하나씩 차례로 선형적으로 계획하는 함정을 피하십시오. 그 대신 빠르게 시작하여, 가능한 한 많은 일을 가능한 한 빨리 동시에 진행하십시오. 이렇게 하면 범위, 예산, 자원, 일정이 거시적 수준에서 서로 비교적 잘 맞아떨어지는지 감을 잡을 수 있습니다. 그렇지 않다는 것을 알게 되면 즉시 경영진에게 보고하십시오.
• 상시적 긴급성: 모든 현대 프로젝트가 전개되는 살아 있는 질서 속에서 상시적 긴급성은 새로운 자연법칙입니다. 전통적인 기하학적 질서 형태의 프로젝트 관리에서는 일을 선형적이고 단계적인 방식으로 처리할 시간과 자원이 충분하다고 가정할 수 있었습니다. 그러나 현대 세계에서는 그런 경우가 드뭅니다. 모든 프로젝트에 어느 정도의 긴급성이 따른다는 사실에 익숙해지십시오. 이 때문에 여러분과 팀이 얼어붙지 않도록 하십시오. 그 대신 긴급성을 원동력으로 삼아 더 민첩하고, 기민하며, 유연한 프로젝트 관리 기법을 활용하십시오.
• 프로젝트 문서를 눈에 잘 띄게 게시하십시오: 중요한 문서를 눈에 잘 띄는 곳에 두면 팀이 집중력을 유지하는 데 도움이 되며, 특히 먼저 모든 사람에게 서명을 받아 두면 더욱 그렇습니다. 또한 필요할 때 팀이 문서를 갱신하도록 독려하는 효과도 있습니다.
• 오류에 대비하여 계획하십시오: 여러분과 팀은 특히 프로젝트 초기 단계에서 거의 확실히 실수를 하게 됩니다. 그러므로 이에 대비하여 계획하십시오. 무엇이 잘못될 수 있는지, 그리고 어떻게 궤도를 수정할 수 있는지 계속 미리 생각하십시오. 비상 계획을 늘 준비해 두는 습관을 들이십시오.
• 승인 기준 또는 인수 기준을 정의하십시오: 성공을 정의하는 좋은 방법 중 하나는 승인 기준, 또는 때로 인수 기준이라고 불리는 것을 작성하는 데서 시작하는 것입니다. 이는 프로젝트의 각 핵심 단계에 대해 합의된 산출물로, 이것이 갖추어지면 해당 단계가 완료된 것으로 간주할 수 있습니다. 이러한 기준을 대금 지급과 연계하는 것이 일반적입니다. 이러한 기준을 초기에 정의해 두면 좋은 점은, 기준이 대개 매우 객관적이고 언제든 다시 참조할 수 있으므로 모든 활동이 최종 산출물과 일치하도록 보장할 수 있다는 것입니다. 프로젝트가 성공했는지를 두고 벌어지는 큰 의견 충돌은 대개 인수 기준을 정의하지 못한 데서 비롯됩니다. 이에 대한 합의를 이루는 것은 필수적입니다. 그것이 다른 모든 것(자원, 시간, 예산 등)을 좌우하기 때문입니다.
• 변화에 대비하십시오: 프로젝트 착수와 관련된 문서를 모두 작성했다고 해서 모든 것이 확정되었다고 착각하지 마십시오. 살아 있는 질서 속에서 발생하는 지속적인 변화를 미리 예견하기란 불가능한 경우가 많습니다.

~요약

• 프로젝트 착수는 프로젝트 전체의 토대를 마련하는 일입니다. 착수는 프로젝트의 공식적인 시작을 의미하지만, 미래를 내다보며 제작 단계, 운영/사용/변경 단계, 폐기/재사용 단계를 포함하는 프로젝트의 전체 생애주기를 구상하는 일을 수반합니다. 보다 전통적인 관점에서 프로젝트 관리를 바라보더라도, 프로젝트 관리의 단계들은 대개 서로 겹치며 착수 단계에서 작성한 문서를 다시 살펴보는 일이 자주 수반됩니다.
• 착수 단계에서 작성되는 이러한 문서는 일반적으로 프로젝트에 대한 개괄적인 관점을 제공합니다. 여기에는 프로젝트 헌장, 범위 기술서, 비즈니스 케이스가 포함됩니다. 이러한 문서를 작성하면서 계획 단계에서 작성할 다음 항목들도 미리 염두에 두어야 합니다. 작업분류체계(WBS), 조직분류체계(OBS), 작업 패키지, 책임 할당 매트릭스(RAM)가 그것입니다.
• 숙련된 프로젝트 관리자는 프로젝트에서 "성공"이 무엇을 의미하는지 정의하고 그것을 어떻게 측정할지 결정함으로써 빠르게 시작해야 한다는 것을 알고 있습니다. 성공은 산업마다 다른 의미를 지닙니다. 예를 들어 자본 프로젝트에서는 총소유비용(건물의 건설 및 사용과 관련된 직접비와 간접비의 총합)이 건물의 성공 여부를 판단하는 데 결정적인 역할을 합니다. 프로젝트의 성공을 정의할 때는 불필요한 세부 사항까지 들어가지 않는 선에서 최대한 구체적으로 정의하십시오. 전통적인 프로젝트 관리자는 프로젝트를 일정 내에, 예산 범위 안에서 완료하는 것을 기준으로 성공을 정의하는 경향이 있습니다. 그러나 린(Lean)은 더 폭넓은 성공의 정의를 전제로 합니다. 즉, 낭비를 제거하고 가치를 극대화하는 것을 우선시하며, 그 과정에서 아직 예상하지 못한 프로젝트로까지 이어질 고객 충성도를 쌓는 것입니다. 애자일에서 성공이란 각 스프린트가 끝날 때마다 작동하는 소프트웨어를 인도하고, 궁극적으로는 일정과 예산이 허용하는 한 최대한 많은 작동하는 소프트웨어를 인도하는 것을 의미합니다.
• 잘 정의된 프로젝트 헌장은 프로젝트의 목표를 정의하며, 이 목표는 다시 전체 조직, 일정, 인력, 그리고 궁극적으로 수행될 작업을 결정합니다.
• 프로젝트 관리의 세 가지 제약 조건인 범위, 예산, 일정 가운데 범위는 확정하기가 가장 어렵습니다. 가장 단순한 프로젝트를 제외하면, 어떤 범위 정의든 프로젝트와 고객의 요구 사항을 더 많이 알게 됨에 따라 거의 확실히 진화할 것입니다. 범위 진화라는 용어는 모든 이해관계자가 동의하고 그에 상응하는 예산 및 일정 변경이 수반되는 변경을 가리킵니다. 궁극적으로 범위의 정의는 고객이 원하는 것에 기반하지만, 고객이 무엇이 가능한지 모를 수도 있으므로 때로는 고객이 프로젝트 범위를 정의하도록 안내해야 합니다. 시간을 들여 범위 기술서의 형태로 범위를 신중하게 명확히 표현하십시오. 범위 기술서를 작성한 후에는 범위 크리프라고 불리는 승인되지 않은 변경을 피하기 위해 이를 정기적으로 참조하십시오.
• 프로젝트의 범위는 해결하려는 문제의 종류에 따라 결정됩니다. 기술적 문제에는 명확한 해결책이 있으며, 이는 엔지니어들이 전통적으로 제공하도록 훈련받아 온 종류의 해결책입니다. 적응적 문제의 경우에는 상황이 덜 명확하고, 어떻게 진행할지에 대한 확실한 합의가 없으며, 어떤 해결책이든 이해관계자의 가치관과 신념에 도전하게 될 것이 분명합니다. 어떤 문제는 두 가지가 섞여 있습니다.
• 모든 프로젝트는 여러 맥락 안에서 진행됩니다. 즉, 조직적 맥락(여러분의 조직과 고객의 조직 모두), 시장 맥락, 기술적 맥락, 사회적 맥락 안에서 진행됩니다. 이 모든 맥락은 프로젝트 수명 주기 동안 변할 수 있으며, 현대 비즈니스 세계의 끝없는 급류 속에서는 아마도 실제로 변할 것입니다. 프로젝트의 맥락이 변하면 프로젝트도 필연적으로 진화합니다. 프로젝트 관리자로서 여러분의 임무는 프로젝트의 맥락에 영향을 미칠 수 있는 외부 요인을 주시하는 것입니다.

용어집

• 비즈니스 케이스—"의사 결정권자가 어떤 조치를 승인하도록 설득하기 위한, 대개 문서화된 논거입니다. 그 문서 자체를 비즈니스 케이스라고 부르기도 합니다. 일반적으로 비즈니스 케이스는 매력적인 투자 수익률(ROI)에 이르는 명확한 경로를 제시해야 합니다. 가장 단순한 형태의 비즈니스 케이스는 구두로 하는 제안일 수도 있습니다…. 더 복잡한 사안의 경우에는 비즈니스 케이스를 신중하게 구성된 문서로 제시해야 합니다. 비즈니스 케이스 문서는 조치를 취하는 경우와, 반대로 조치를 취하지 않는 경우 모두에 수반되는 이점과 위험을 검토해야 합니다. 결론은 실행을 위한 설득력 있는 논거여야 합니다"(TechTarget n.d.).
• 맥락—Merriam-Webster에 따르면 "어떤 일이 일어나는 상황, 즉 어떤 일이 일어나는 장소와 시점에 존재하는 조건들의 집합"입니다.
• 아이디어 평균화—어느 것에도 온전히 전념하지 않은 채 이 아이디어에서 조금, 저 아이디어에서 조금, 또 다른 아이디어에서 조금씩 가져오는 것입니다.
• 선형 책임 차트(linear responsibility chart)—RACI 차트를 참조하십시오.
• 조직분류체계(OBS)— 프로젝트 팀에 대한 기술입니다. 조직분류체계는 "누가 누구에게 보고하는지, 위계의 세부 사항, 그리고 보고 체계를 설명합니다…. 조직분류체계는 보통 그래프나 차트를 사용해 시각적으로 전달됩니다. 프로젝트 관리자나 총괄 관리자를 맨 위에 두고, 그 아래에 제품 개발, 설계, 자재 관리, 생산 등 여러 부서를 둘 수 있습니다"(Bradley n.d.). 함께 참조: 책임 할당 매트릭스(RAM)(아래 항목).
• 계획 편향(planning bias)—작업을 완료하는 데 필요한 시간을 낙관적으로 과소평가하는 경향입니다.
• 프로젝트 헌장— 프로젝트 착수와 계획 수립을 위한 "단일하고 통합된 정보원"(Richter 2014)입니다. 프로젝트 헌장은 프로젝트에 대해 현재 알고 있는 내용을 기술하며, 모든 이해관계자의 이름, 조직의 요구 사항에 대한 기술, 프로젝트에 이르기까지의 경위, 프로젝트의 목적, 산출물, 역할과 책임 등의 정보를 담습니다. 프로젝트 헌장은 프로젝트 개요서라고 불리기도 합니다. 프로젝트 헌장을 프로젝트 팀과 프로젝트 후원자 사이의 계약으로 생각하면 도움이 될 때가 있습니다.
• 프로젝트 착수(project initiation)—프로젝트 전체의 기반을 다지는 초기 단계입니다.
• 프로젝트 개요서(project overview statement)—프로젝트 헌장을 참조하십시오.
• 프로젝트 범위(project scope)—"프로젝트가 제공하는 제품이나 서비스를 제공하기 위해 수행해야 하는" 모든 작업입니다(Martinez n.d.).
• 책임 할당 매트릭스(RAM)—조직분류체계의 한 유형으로, 격자 형태를 띠며 일반적으로 첫 번째 열에 프로젝트 작업을, 맨 위 행에 이해관계자를 나열하고 각 작업을 여러 이해관계자에게 할당합니다. 이를 사용해 프로젝트에 필요한 자원이 충분한지 판단하고, 누가 무엇을 책임지는지 기록할 수 있습니다. RACI 차트도 참조하십시오.
• RACI 차트—책임 할당 매트릭스(RAM)의 한 유형입니다. 선형 책임 차트라고도 합니다. "RACI"라는 이름은 "responsible(실행 책임), accountable(최종 책임), consult(협의), inform(통보)"의 머리글자를 딴 것입니다.
• 이해관계자(stakeholders)—프로젝트의 영향을 받거나 프로젝트에 영향을 줄 수 있는 사람들입니다.
• 범위 크리프—예산과 일정에 대한 상응하는 승인된 변경 없이 프로젝트에 발생하는 통제되지 않은 변경입니다.
• 범위 기술서(scope statement)—프로젝트의 범위(또는 요구 사항)를 정의하는 문서입니다.
• 작업분류체계(WBS)—프로젝트 산출물과 관련된 작업에 대한 기술로, 흔히 트리 다이어그램 형태를 띱니다. 작업분류체계는 "각 작업이 다른 작업, 전체, 그리고 최종 산출물(목표 또는 목적)과 맺는 관계를 보여 줍니다. 또한 책임의 배분을 보여 주고, 프로젝트 모니터링과 관리를 위해 각 단계에서 필요한 자원과 가용 시간을 파악합니다"(Business Dictionary n.d.).
• 작업 패키지(work package)— "프로젝트 내에서 서로 관련된 작업의 묶음입니다. 작업 패키지는 그 자체로 프로젝트처럼 보이기 때문에, 흔히 더 큰 프로젝트 안의 하위 프로젝트로 여겨집니다. 작업 패키지는 작업분류체계(WBS)를 만들 때 프로젝트를 쪼갤 수 있는 가장 작은 작업 단위입니다"(Wrike n.d.).

~참고 문헌

Beedle, Mike, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Andrew Hunt, et al. n.d. "Principles behind the Agile Manifesto." AgileManifesto. 2018년 6월 16일 접속. http://agilemanifesto.org/principles.html.

Bigelow, Brad. 2012. “범위–모호한 제약 조건 정복하기(Scope–Mastering the Fuzzy Constraint).” PMI(Project Management Institute). 2018년 6월 16일 접속. http://www.pmi.org/~/media/Members/Requirements-Management/Scope%20Mastering%20the%20Fuzzy%20ConstraintBigelow.ashx.

Bradley, Jeremy. n.d. “조직분류체계(OBS)란 무엇인가?(What Is an Organizational Breakdown Structure (OBS)?)” Chron. 2018년 6월 16일 접속. http://smallbusiness.chron.com/organizational-breakdown-structure-obs-72523.html.

Business Dictionary. n.d. “외부 요인(Externalities).” BusinessDictionary. 2018년 6월 16일 접속. http://www.businessdictionary.com/definition/externalities.html.

—. n.d. “작업분류체계(WBS).” BusinessDictionary. 2018년 6월 16일 접속. http://www.businessdictionary.com/definition/work-breakdown-structure-WBS.html.

Carlson, Nicholas. 2013. “페이스북의 새 모바일 제품은 아이폰 사용자들이 만들었기 때문에 크게 실패했습니다(Facebook’s New Mobile Product Is A Huge Flop Because It Was Built By iPhone Users).” Business Insider, 5월 13일. http://www.businessinsider.com/facebook-made-a-simple-huge-mistake-building-home-which-looks-like-a-bigger-flop-by-the-second-2013-5.

Doglione, Cara. 2018. “책임 할당 매트릭스(RACI 매트릭스) 이해하기(Understanding Responsibility Assignment Matrix (RACI Matrix)).” PM. 1월 25일. http://project-management.com/understanding-responsibility-assignment-matrix-raci-matrix/.

Feldsher, Roni. 2016. “프로젝트 범위 기술서에 포함해야 할 내용(What to include in a project scope statement).” Clarizen. 7월 9일. https://www.clarizen.com/what-to-include-in-a-project-scope-statement/.

Franzen, Carl. 2014. “The history of the Walkman: 35 years of Iconic Music Players.” The Verge, 7월 1일. http://www.theverge.com/2014/7/1/5861062/sony-walkman-at-35.

Friedman, Thomas L. 2005. The World is Flat: A Brief History of the Twenty-first Century. New York: Farrar, Straus and Giroux. https://books.google.com/books?id=-mv_ryTuvo0C&pg=PA418&lpg=PA418&dq=well+educated+workforce+in+Ireland+results&source=bl&ots=xgXHeV0Ozx&sig=JoHGEs28SPnl9ZgKqUcsZusucbs&hl=en&sa=X&ved=0ahUKEwj9hYvBlL_YAhVJ94MKHdStCE4Q6AEIUjAG#v=onepage&q=well%20educated%2.

Harvard Business School Publishing Corporation. 2006. 크고 작은 프로젝트 관리하기: 예산과 일정을 지키며 성과를 내기 위한 기본 역량(Managing Projects Large and Small: The Fundamental Skills for Delivering on Budget and on Time). Boston: Harvard Business School Publishing Corporation.

Heifetz, Ronald A., Marty Linsky, and Alexander Grashow. 2009. The Practice of Adaptive Leadership: Tools and Tactics for Changing Your Organization and the World. Boston: Harvard Business Press.

Hill, Andrew. 2016. How to Avoid Idea Averaging: Let only the best ideas through. 1월 4일. http://andrewxhill.com/blog/2016/01/04/idea-averaging/.

Investopedia. n.d. “산출물(deliverables).” Investopedia. 2018년 6월 15일 접속. https://www.investopedia.com/terms/d/deliverables.asp.

—. n.d. “외부 요인(externality).” Investopedia. 2018년 6월 15일 접속. https://www.investopedia.com/terms/e/externality.asp.

Jordan, Andy. 2012. “성공적인 프로젝트 착수의 9가지 비결(The 9 Secrets of Successful Project Initiation).” ProjectManagement.com. 3월. http://www.projectmanagement.com/pdf/attaskinitiation.pdf.

Kanter, James. 2009. “In Finland, Nuclear Renaissance Runs Into Trouble.” The New York Times, 5월 28일. http://www.nytimes.com/2009/05/29/business/energy-environment/29nuke.html?_r=0.

Martinez, Michael. 연도 미상. 프로젝트 관리 범위(Project Management Scope). 2018년 6월 16일 접속. https://www.project-management-skills.com/project-management-scope.html.

McCracken, Harry. 2013. “This Dumb Year: The 47 Lamest Moments in Tech 2013.” Time, 12월 31일. http://techland.time.com/2013/12/31/this-dumb-year-the-47-lamest-moments-in-tech-2013/.

Meißner, M., and L. Blessing. 2006. “적응형 제품 개발 방법론 정의하기(Defining an Adaptive Product Development Methodology).” DESIGN 2006 국제 디자인 학술대회 논문집(Proceedings of the DESIGN 2006 International Design Conference). Dubrovnik, Croatia: Design Society. 69-78.

Mucha, Michael, 인터뷰어: Ann Shaffer. 2017. Technical and Adaptive Problems (12월 11일).

OptiSol. n.d. “애자일 개발에서 범위 크리프란 무엇인가?(What is Scope Creep in Agile Development?)” Optisol Business. 2018년 6월 17일 접속. https://www.optisolbusiness.com/insight/what-is-scope-creep-in-agile-development.

Porter, Michael E., and Thomas Lee, MD Lee. 2013. “The Strategy That Will Fix Health Care.” Harvard Business Review, 10월. https://hbr.org/2013/10/the-strategy-that-will-fix-health-care.

Portny, Stanley E. n.d. “프로젝트 범위 기술서에 포함해야 할 내용(What to Include in a Project Scope Statement).” Dummies. 2018년 6월 15일 접속. http://www.dummies.com/careers/project-management/what-to-include-in-a-project-scope-statement/.

Richter, Linda. 2014. “프로젝트 헌장이란 무엇인가?(What Is a Project Charter?)” Bright Hub 프로젝트 관리(Bright Hub Project Management). 10월 24일. http://www.brighthubpm.com/project-planning/5161-what-is-a-project-charter/.

Rife, Matt. 2005. “Pentagon Rebuild is Modern-Day Study in Design-Build Construction Method.” Austin Business Journal, 11월 13일. http://www.bizjournals.com/austin/stories/2005/11/14/focus3.html.

Tate, Ryan. 2013. “페이스북 홈은 성공하기 전까지는 ‘엄청난 실패작’일 것입니다(Facebook Home Will be a “Huge Flop” Until It’s Not).” Wired, 5월 14일. http://www.wired.com/2013/05/facebook-home-criticism/.

TechTarget. n.d. “비즈니스 케이스(business case).” WhatIs. 2018년 6월 16일 접속. http://whatis.techtarget.com/definition/business-case.

United States Environmental Protection Agency. 연도 미상. Design for the Environment Life-Cycle Assessments. 2018년 6월 16일 접속. https://www.epa.gov/saferchoice/design-environment-life-cycle-assessments.

Wrike. n.d. “프로젝트 관리 가이드/프로젝트 관리에서 작업 패키지란 무엇인가?(Project Management Guide/What is a Work Package in Project Management?)” Wrike. 2018년 6월 16일 접속. https://www.wrike.com/project-management-guide/faq/what-is-a-work-package-in-project-management/.