변화 외에 영원한 것은 없습니다.
헤라클레이토스, 기원전 535 – 475년

1.1 현대 사회의 기술 프로젝트 관리

프로젝트는 정의상 일시적입니다. 조직의 필요에 따라 생겼다가 사라지며, 결국에는 종료됩니다. Cambridge English Dictionary에 따르면 프로젝트란 "일정 기간에 걸쳐 완료되며 특정한 목적을 달성하기 위한 계획된 작업 또는 활동"입니다(2018). 프로젝트가 이처럼 일시적이기 때문에, 프로젝트 관리 역량이 최적 수준에 미치지 못하는 조직은 프로젝트를 관리하기 위한 체계적인 프로세스를 마련하지 못하는 경우가 많습니다. 프로젝트가 끝나면 모두가 이전 프로젝트에서 무엇이 효과가 있었고 무엇이 그렇지 않았는지 거의 돌아보지도 않은 채 다음 프로젝트를 준비하며 넘어갑니다. 다시 말해, 이러한 조직에는 프로젝트 관리, 즉 "프로젝트 목표를 달성하기 위해 프로세스, 방법, 지식, 기술, 경험을 적용하는 것"(Association for Project Management n.d.)에 대한 일관된 접근 방식이 부족합니다. 이러한 체계적 접근 방식의 부재는 기술 분야에서 특히 문제가 되며, 여러 산업 전반에 걸쳐 기술 프로젝트의 실패율을 극도로 높이는 원인이 됩니다.

기술 프로젝트의 성공률을 웹에서 잠깐만 검색해 보아도 놀라운 사실과 수치를 접할 수 있습니다. 어떤 연구를 보느냐에 따라 다르지만, 프로젝트 실패율은 20퍼센트에서 80퍼센트에 이릅니다. 게다가 문제에 돈을 더 쏟아붓는다고 해서 도움이 되지도 않습니다. 실제로 프로젝트 예산이 클수록 실패할 가능성도 높아집니다(Mieritz 2012). 한 연구에 따르면 예산이 1,500만 달러를 넘는 IT 프로젝트는 프로젝트 관리 측면에서 처참한 실패작입니다. "대규모 IT 프로젝트는 평균적으로 예산을 45퍼센트, 일정을 7퍼센트 초과합니다"(Bloch, Blumberg and Laartz 2012). 산업 메가프로젝트, 즉 비용이 10억 달러를 넘는 산업 프로젝트의 경우에는 평가가 한층 더 암울합니다. Edward W. Merrow에 따르면 "석유 및 가스 생산 부문의 성적이 가장 나쁩니다. 이 산업 부문의 메가프로젝트 중 78퍼센트가 실패로 분류됩니다"(2011, 49).

전문적인 프로젝트 관리의 가치

조직은 어떻게 이 수렁에서 빠져나올 수 있습니까? 이 책 전반에서 다루는 역량을 중시하는, 체계적이고 전문적인 프로젝트 관리 문화를 만들어 내면 됩니다. 기술 프로젝트 관리 기법과 프로세스를 도입한 조직이 프로젝트 성공이라는 풍성한 보상을 거둔다는 사실은 연구를 통해 일관되게 입증되고 있습니다. 이 책은 유연하고 적응력이 있으며 새로운 배움에 열려 있는 기술 프로젝트 관리 접근 방식을 기르는 데 초점을 맞춥니다. 실용적인 제안을 많이 담고 있지만, 구체적인 방법론을 자세히 다루지는 않습니다. 프로젝트 관리의 세부적인 실무 지침은 Erik W. Larson과 Clifford Gray의 Project Management: The Managerial Process를 참고하십시오.

문화의 영향

모든 프로젝트는 내부 및 외부 요인의 영향을 받는, 고유하고 변화하는 맥락 속에서 전개됩니다. 그러한 요인 중 하나인 문화는 프로젝트의 맥락과 결과에 지대한 영향을 미칠 수 있습니다. 여러분은 아마 특정 사회, 집단, 장소 또는 시대의 규범, 신념, 관습의 총체인 문화라는 개념에 익숙할 것입니다. 문화는 인간 사회의 여러 층위, 즉 지역, 민족 집단, 종교, 가족, 조직, 심지어 프로젝트에서도 작용합니다.

동일한 도구, 계약, 구조를 사용하는 프로젝트라도 조직과 프로젝트 팀의 문화에 따라 결과가 크게 달라질 수 있습니다. 조직 문화는 조직을 이루는 행동, 가치, 인공물, 보상 체계, 의례의 총체로 구성됩니다. 조직의 문화는 기대되는 일련의 행동(예: 사람들이 고객 및 서로와 어떻게 협업하는지, 얼마나 일찍 또는 늦게까지 일하는지), 조직의 보상 체계 구조(예: 직원이 비용 절감, 고객 만족, 혁신 또는 기타 요인 중 무엇으로 보상받는지), 위험에 대한 접근 방식, 그리고 전반적인 사명과 전략으로 드러날 수 있습니다(Bersin 2015). 프로젝트 문화, 즉 프로젝트에 참여하는 개인과 무관하게 존재하는 신념, 태도, 행동의 총체는 강력한 힘이 될 수 있으며, 그 결과 프로젝트에 새로 합류한 사람들은 기존 문화를 바꾸기보다 그 문화에 적응하는 경우가 많습니다. 모든 층위에서 문화를 이끄는 것은 리더십입니다(2015).

문화의 빙산이라는 개념은 문화의 많은 측면이 외부인에게는 드러나지 않는다는 점을 일깨워 줍니다. 조직이나 프로젝트 팀에서 명시된 규범, 허용되는 관행, 전략으로 이루어진 표층 문화는 전체 문화의 극히 일부에 불과한 경우가 많습니다. 문화의 훨씬 더 많은 측면이 수면 아래에 자리하고 있으며, 팀원들이 함께 일하는 방식에 훨씬 더 강한 영향을 미치는 경우가 많습니다. 이러한 심층 문화 요소에는 의사소통 방식과 규칙, 리더십에 대한 관념, 자아와 시간에 대한 개념, 권위와 협업에 대한 태도, 의사 결정과 문제 해결에 대한 접근 방식 등이 있습니다.

조직 문화와 프로젝트 문화의 심층 요소를 보여 주는 단서는 뜻밖의 곳에서 발견되는 경우가 많습니다. 예를 들어 조달 관행은 문화에 대해 많은 것을 드러냅니다. 조달 방식이 가격 중심이라면 그 조직 문화와 프로젝트 문화는 거래 중심적이며, 어쩌면 적대적일 가능성이 높습니다. 반대로 조달이 가치 중심이라면 그 문화는 관계 중심적일 가능성이 더 높습니다.

프로젝트 리더는 조직 문화와 프로젝트 문화의 모든 측면을 깊이 살펴야 하며, 여기에는 표면적 요소가 심층 문화의 실질적 요소와 어긋나는 지점도 포함됩니다. 보잉의 엔지니어링 관리자인 Vera Martinovich 역시 프로젝트 수준이든 조직 수준이든 문화가 양질의 프로젝트 결과를 성공적으로 산출하는 데 걸림돌이 되어 가는 시점을 알아차리는 것이 중요하다고 강조합니다. 마르티노비치에 따르면, 이는 기존 조직 문화에 맞서 싸우기보다 그 안에서 프로젝트 팀이 성공적으로 일할 수 있도록 돕는 것을 의미할 수도 있습니다(개인 서신, 2020년 6월 20일).

여러 조직 출신의 사람들로 구성된 프로젝트 팀에서는 문화와 관련된 추가적인 어려움이 생길 수 있으며, 이는 많은 산업에서 흔히 볼 수 있는 일입니다. 이러한 팀의 예로는 공급업체의 설계를 활용하는 제품 개발 팀, 독립 설계자와 시공업체가 참여하는 건설 프로젝트 팀, 구매한 제품을 도입하기 위해 외부 컨설턴트와 함께 일하는 소프트웨어 프로젝트 팀 등이 있습니다. 이런 팀에서는 공통의 조직 문화가 보장되지 않습니다. 이 경우 프로젝트 리더는 고유한 프로젝트 문화의 분위기를 정할 기회를 갖게 되며, 이 문화는 최종 고객의 문화와 맞아야 합니다.

팀의 구성이 어떠하든, 외부 요인의 영향이 어떠하든, 프로젝트 리더의 역할은 팀원과 기타 이해관계자가 공동의 목표를 향해 일하도록 북돋우는 프로젝트 문화를 구축하는 것입니다. 이를 이루려면 프로젝트 리더는 자신의 영향력을 인식해야 하며, 여기에는 자신이 프로젝트 문화에 부정적인 영향을 미치고 있을 수도 있는 방식까지 포함됩니다. 예를 들어, 어려운 결정을 내리고 팀에 책임을 묻는 일을 희생하면서까지 소극적으로 모든 사람과 친하게 지내려는 프로젝트 리더는 결국 팀의 가장 큰 걸림돌이 될 수 있습니다. 마찬가지로, 의견을 구하지 않고 팀을 대신해 행동하는 독단적인 프로젝트 관리자나 권력의 원천으로 삼기 위해 의도적으로 정보를 감추는 관리자는 프로젝트 문화를 망가뜨리고 성공적인 성과를 거둘 가능성을 크게 떨어뜨릴 수 있습니다.

프로젝트 팀에 신뢰와 유연성의 문화가 있느냐 없느냐가 성공과 실패를 가를 수 있습니다. 프로젝트 리더는 협력적인 문화를 조성함으로써 품질을 달성하고 문제가 발생했을 때 이를 해결하는 팀의 역량을 강화합니다.

프로젝트의 문화를 숙달하고, 그 문화에 영향을 미치고, 그것을 바꾸는 데에는 시간과 인내가 필요합니다. 자신이 일하고 있는 문화를 파악하는 동안에는 열린 마음을 가지십시오. 귀 기울이고, 적응하고, 인내하십시오. 문화의 어떤 측면을 바꿔 나갈지 결정할 때는 신중하게 판단하십시오. 먼저 프로젝트의 문화를 인식하는 데서 출발하고, 가능할 때마다 그 문화를 받아들이며 자신의 일하는 방식을 조정하십시오.

1.2 고슴도치이자 여우가 되십시오

알렉산더 라우퍼(Alexander Laufer)는 자신의 책 Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results에서 철학자 이사야 벌린(Isaiah Berlin)이 널리 알린 고슴도치와 여우의 비유를 빌려 프로젝트 관리자의 두 가지 필수 자질을 설명합니다.

여우의 장점은 세상을 복잡하게 이해하기 때문에 여러 가능성을 시도해 보고, 현재 상황에 맞추어 전략과 전술을 조정할 수 있다는 것입니다. 고슴도치에게는 모든 경험을 "자신이 하는 모든 일을 통합하고 이끄는 하나의 포괄적인 개념"으로 단순화할 수 있게 해 주는 하나의 거대한 전략이 있습니다. 조직 전략을 다루는 2강에서 보게 되겠지만, 조직의 미래에 관한 장기적인 결정을 내릴 때에는 고슴도치의 접근 방식이 더 바람직합니다. 그러나 프로젝트 관리에서는 두 전략 모두 강력하며, 상황에 따라 둘 다 효과적일 수 있습니다. Laufer는 성공적인 관리자는 "고슴도치처럼 행동하기도 하고 여우처럼 행동하기도 하지만, 운전석에는 고슴도치를 앉힌다"고 주장합니다.

이 과정 전반에 걸쳐 우리는 열린 마음을 유지하고 특정 프로젝트에서 활용할 수 있는 여러 공격 방법을 탐색함으로써, 기술 프로젝트 관리에 여우 같은 접근 방식을 취할 것입니다. 그러나 동시에 몇 가지 기본 원칙, 특히 린 프로젝트 관리의 기본 원칙을 고슴도치처럼 강조할 것입니다. 또한 우리의 모든 논의는 프로젝트 관리의 두 가지 근본적인 접근 방식, 즉 전통적이고 예측적인 기하학적 질서 접근 방식과 보다 적응력 있는 살아 있는 질서 접근 방식 사이의 구분을 바탕으로 이루어질 것입니다.

1.3 두 가지 유형의 질서: 살아 있는 질서와 기하학적 질서

프랑스 철학자 Henri Bergson은 1907년 저서 창조적 진화에서 인간 창의성의 본질과 그것이 질서와 맺는 관계를 탐구했습니다. Bergson에 따르면, 우리는 일반적으로 “질서”라는 말로 사물들 사이의 기계적이고 미리 정해진 선형적 관계를 의미합니다. 사건 A는 사건 B로 이어지고, 사건 B는 사건 C로 이어지며, 사건 C는 사건 D로 이어지는 식으로, 변화나 적응의 여지가 전혀 없습니다. 또한 우리는 창의성을 무질서한 상태, 즉 어떤 유형의 질서도 드러나지 않을 때에만 생겨나는 것으로 여기는 경향이 있습니다. 자유분방한 예술가는 이러한 사고방식에 기반한 고정관념입니다. 그러나 Bergson은 우리가 창의성과 연관 짓는 무질서가 실제로는 다른 유형의 질서일 뿐이라고 주장했습니다(222-224).

다시 한번 Alexander Laufer의 견해를 살펴봅시다. 그는 Bergson의 저작에서 프로젝트 관리에 관한 몇 가지 강력한 통찰을 이끌어 냈으며, 이를 다음과 같이 요약합니다.

이 책 전반에 걸쳐 우리는 창의적이고 현실적이며 기능적인 프로젝트 관리 접근 방식을 개발하는 것을 목표로, 기하학적 질서와 살아 있는 질서를 살펴보고 비교할 것입니다.

살아 있는 질서와 기하학적 질서의 특성

프로젝트 관리에서 기하학적 질서는 전통적인 관리 사고와 일치합니다. 이러한 질서 개념은 그림 1-1에 나타난 관계처럼, 한 단계가 반드시 다음 단계로 이어지는 개발 단계 사이의 예측 가능한 관계와 연관됩니다.

프로젝트 관리자들은 전통적으로 이처럼 질서 정연한 프로젝트 진행을 이상으로 여겨 왔습니다. 실제로 이는 PMI(Project Management Institute)와 같은 조직이 주로 중점을 두어 온 예측적이고 프로세스 지향적인 프로젝트 관리 접근 방식의 원동력입니다. 이는 프로젝트 관리의 필수 요소이며, 경험이 부족한 프로젝트 관리자는 자기 업무에 대한 기하학적 접근 방식을 숙달하는 것부터 시작해야 합니다. 그러나 기하학적 질서 사고에만 의존하면 비효율적이고 효과 없는 결과로 이어질 수 있습니다.

이와 대조적으로, 살아 있는 질서의 사고방식은 사물로 이루어진 시스템이 언제나 스스로를 다시 만들어 가는 과정에 있으며, 시스템은 언제나 어느 수준에서는 불확실성의 상태에 있다는 점을 인정합니다. 프로젝트 관리에서 이는 프로젝트가 역동적인 환경에서 일어나며, 예기치 않은 사건을 복잡한 프로젝트 생애 주기의 일부로 간주해야 한다는 것을 시사합니다. 이는 숙련된 프로젝트 관리자가 시간이 흐르면서 터득하는 것입니다. 그러나 경험이 부족한 프로젝트 관리자라도 살아 있는 질서에 대한 이해를 자신의 업무에 반영하려고 노력할 수 있습니다.

그림 1-2는 살아 있는 질서와 기하학적 질서의 특성을 보여 줍니다. 하나의 프로젝트가 두 가지 질서의 특성을 모두 지닐 수 있다는 점을 명심하십시오.

어떤 상황에서는 기하학적 질서의 방법을, 또 다른 상황에서는 살아 있는 질서의 방법을 사용해야 할 수도 있습니다. 예를 들어, 날씨가 날마다 거의 변하지 않는 샌디에이고에서 평범한 날의 일기 예보를 준비하는 것은 기하학적 질서의 작업입니다. 이와 대조적으로, 5일 후에 허리케인이 해안에 상륙할 것으로 예상되는 플로리다 해안의 일기 예보를 준비하는 것은 살아 있는 질서의 프로젝트입니다. 계획 단계는 살아 있는 질서 속에서 진행되는 경우가 많습니다. 그런 다음 프로젝트와 예상되는 상황에 대해 더 많이 알게 되면서, 실행은 기하학적 질서 속에서 진행됩니다. 그러나 예기치 않은 일이 일어나면 갑자기 다시 살아 있는 질서 속으로 내던져질 수 있습니다. 필요에 따라 상황에 적응하면서 기하학적 질서의 기법과 살아 있는 질서의 기법 사이를 오갈 준비가 되어 있어야 합니다.

전통적인 프로젝트 관리 프로세스는 프로젝트를 가장 세세한 부분까지 계획할 수 있으며, 계획 단계가 끝나면 프로젝트 관리자의 일은 예기치 않은 일 없이 그 계획에 따라 프로젝트를 실행하는 것이라는 전제 위에 세워졌습니다. 현대 세계의 현실은 이와 전혀 다릅니다. 피터 베일(Peter Vaill)은 1991년 저서 Managing as a Performing Art: New Ideas for a World of Chaotic Change Permanent에서 오늘날의 조직이 실제로는 "영구적인 급류(permanent white water)" 상태에서 운영된다고 주장했습니다. 알렉산더 라우퍼(Alexander Laufer)는 베일의 주장을 다음과 같이 설명합니다.

이 책 전체에 걸쳐 우리는 영구적인 급류의 세계에서 기술 프로젝트를 관리하는 방법에 초점을 맞출 것입니다.

예측할 수 없는 것을 예측하기

인간이 제한된 자원을 가지고 일정 기간에 걸쳐 무언가를 하는 일에는 무엇이든 어느 정도의 예측 불가능성이 따릅니다. 이는 프로젝트가 필연적으로 살아 있는 질서에 의해 형성된다는 것을 의미합니다. 프로젝트를 진행하는 동안 동료와 프로젝트 이해관계자에게서 무엇을 기대할 수 있는지 잘 파악하고 있다고 생각할 수도 있지만, 가장 예측하기 쉽다고 여겼던 특성이 전혀 믿을 수 없는 것으로 드러나는 경우가 많습니다.

얼마 전 이러한 깨달음은 경제학 분야를 뒤흔들었습니다. 경제학은 인간이 자신의 재정적 안녕을 증진하는 선택을 하는 경향에 있어 완전히 예측 가능하다는 가정 위에 세워진 학문이었습니다. 리처드 H. 세일러(Richard H. Thaler)는 행동경제학 분야의 획기적인 연구에서, 사람들이 자기 이익을 위해 합리적으로 행동한다는, 반박할 수 없다고 여겨지던 생각이 기껏해야 논란의 여지가 있으며 아마도 사실이 아닐 것임을 입증했습니다(Knee 2015). 그럼에도 많은 경제학자는 자신들의 기본 원칙을 신뢰할 수 없다는 점을 고려하기를 한결같이 거부합니다. 세일러에 따르면 "경제학자들은 합리적인 사람의 사고에 영향을 미치지 않을 요인은 모두 무시합니다. 이러한 것들은 무관하다고 여겨집니다. 그러나 이론으로서는 불행하게도, 무관하다고 여겨지는 많은 요인이 실제로 중요합니다"(2015).

세일러는 이어서 "당신이 스팍이 아닌 이상" 은퇴 자금 저축에 대해 어떻게 느끼는지와 같은, 무관하다고 여겨지는 것들이 단순한 자기 이익보다 경제적 행동에 훨씬 더 큰 영향을 미칠 수 있다고 주장합니다(2015). 성공적인 프로젝트 관리자가 성공하는 이유 중 하나는, 무관하다고 여겨지는 것들이 프로젝트 결과에 영향을 미치는 힘을 결코 무시하지 않기 때문입니다. 앞으로 함께할 팀원 대다수가 벌컨인이 아닐 것이라고 무리 없이 가정할 수 있으므로, 무관하다고 여겨지는 것들이 결국 여러분이 관리하는 프로젝트에 예상치 못한 영향을 미치게 될 것이라고도 가정하는 편이 좋습니다. 프로젝트가 진행되는 동안 살아 있는 질서가 여러분에게 무엇을 던져 줄지는 결코 알 수 없습니다.

그렇다고 해서 프로젝트 관리자로서 기하학적 질서에 대한 기대를 버려도 된다는 뜻은 아닙니다. 오히려 그 반대입니다. 이 책은 기술 프로젝트 관리에 관한 책이므로, 우리의 사고는 필연적으로 기하학적 질서와 관련될 수밖에 없습니다. 결국 기술 프로젝트에는 예측 가능한 법칙에 따라 성능이 좌우되는 기술 제품과 서비스가 포함됩니다. 중력은 언제나 같은 방식으로 작용하므로, 엔지니어는 이를 고려해야 합니다. 최신 컴퓨터 프로세서도 오늘날의 환경에서는 일정 속도 이상으로 작동할 수 없으므로, 소프트웨어 개발자 역시 이를 고려해야 합니다.

그러나 기술 제품과 서비스 자체가 예측 가능하다고 해서 이를 만들어 내는 데 필요한 프로젝트도 똑같이 예측 가능할 것이라고 생각하는 경향은 경계해야 합니다. 결코 그렇지 않습니다. 이 책은 사람들이 시간에 걸쳐 작업을 수행하는 활동인 관리에 관한 책이므로, 우리의 사고는 살아 있는 질서에 깊이 뿌리를 두게 될 것입니다.

1.4 프로젝트의 생애 주기와 살아 있는 질서

끊임없이 변화하는 살아 있는 질서의 본질에 눈을 뜨면, 프로젝트의 생애 주기 전반에 내재된 변화의 가능성을 이해하기 시작할 수 있습니다. 프로젝트의 결과물도 마찬가지입니다. 그것이 건물이든, 새 스마트폰이든, 농기계용 소프트웨어이든 말입니다. 프로젝트의 산출물, 즉 결과물은 그 수명 동안 여러 프로젝트에 의해 만들어지고, 유지되고, 개조되고, 갱신되며, 철거/폐기됩니다. 이러한 각 프로젝트는 살아 있는 질서의 불확실성에 영향을 받으며, 이로 인해 프로젝트의 결과물이 앞으로 어떤 모습이 될지, 그리고 실제로 의도한 목적에 적합한 것으로 판명될지를 예측하기가 더욱 어려워집니다. 이는 결국 모든 프로젝트의 계획 단계를 복잡하게 만들며, 특히 얼마나 쉽게 해체하여 폐기하거나 재활용 및 재사용할 수 있는지로 최종 평가되는 것들의 경우에는 더욱 그렇습니다.

예를 들어, 그림 1-3은 건물의 생애 주기를 보여 줍니다. 첫 번째 단계인 제작 단계는 건물의 시공을 감독하는 프로젝트 관리자의 영역입니다. 건물이 완공되면 프로젝트 관리자는 다른 일로 옮겨 가지만, 건물은 물론 이제 막 기능적 수명을 시작한 것입니다. 운영/사용/변경 단계 동안 건물의 입주자는 제작 단계 전반에 걸쳐 프로젝트 관리자가 내린 결정의 혜택을 누리거나 그로 인해 고통을 겪습니다. 다음으로 폐기/재사용 단계가 이어지는데, 이 단계에서 건물은 아마도 철거되고 그 자리에 다른 무언가가 세워질 것입니다. 그 시점에서 전체 생애 주기가 다시 시작됩니다. 이러한 단계들이 얼마나 순조롭게 전개되는지는 적어도 부분적으로는 제작 단계에서 프로젝트 관리자가 내린 선택에 달려 있습니다. 이러한 이후 단계들을 이해해야만 프로젝트의 진정한 본질을 제대로 이해하고, 프로젝트가 지속적인 가치를 지닌 무언가를 만들어 내도록 보장하는 결정을 내릴 수 있습니다.

소프트웨어 개발에서는 단계 사이의 기간이 건설보다 짧습니다. 건설에서와 마찬가지로, 운영 단계는 생애 주기 과정에서 단연 가장 비용이 많이 드는 부분입니다. 그러나 소프트웨어 제품이 설계된 운영 수명을 넘어서까지 계속 사용되면 운영 비용이 가속적으로 증가할 수 있습니다. 어느 산업에서든, 프로젝트 결과물의 생애 주기를 생각하면 프로젝트 지표에 대한 사고방식이 달라집니다. 그림 1-4에서 볼 수 있듯이, 제작 단계라는 제한된 범위 안에서는 좋은 선택처럼 보이는 것도 전체 생애 주기라는 더 넓은 관점에서 보면 어리석게 보일 수 있습니다.

프로젝트 결과와 프로젝트 성공

가장 좁은 의미에서 프로젝트 결과라는 용어는 범위, 비용, 일정, 품질, 그리고 안전과 같은 기타 사항의 측면에서 측정 가능한 프로젝트의 산출물을 가리킵니다. 더 넓은 의미에서 이 용어는 프로젝트가 더 큰 목표에 비추어 미치는 영향을 가리키기도 합니다. 이러한 의미에서 우리는 공동체의 관점을 취하여, 예를 들어 프로젝트의 다목적 활용 가능성과 궁극적인 재개발을 고려합니다. 예를 들어, 가장 좁은 의미에서 제안된 스포츠 경기장의 바람직한 프로젝트 결과는 계획된 범위, 비용, 일정 등에 따라 건설된 다목적 실내 시설일 수 있습니다. 그러나 더 넓은 의미에서 바람직한 프로젝트 결과는 주변 지역의 재개발과 활성화일 수 있습니다.

프로젝트 성공이라는 용어는 프로젝트가 얼마나 잘 수행되었는지의 정도를 가리키며, 이해관계자들은 각자의 관점에 따라 시간이 지나면서 성공에 대해 서로 다른 정의를 갖게 됩니다. 다시 말해, 프로젝트의 성공에 대한 평가는 주관적인 판단입니다. 이해관계자마다 자신의 기대와 목표에 따라 프로젝트의 전반적인 성공에 대해 처음부터 서로 다른 생각을 갖게 됩니다. 문제를 더 복잡하게 만드는 것은, 시간이 지나면서 이해관계자들이 프로젝트 결과가 실제 세계에서 어떻게 작동하는지에 관한 새로운 정보를 반영하여 프로젝트의 성공에 대한 생각을 수정할 가능성이 높다는 점입니다. 프로젝트 성공의 정의가 변한다는 점은 주택 리모델링이나 도로 재건설처럼 불편을 초래하는 프로젝트를 진행하는 내내 특히 염두에 두어야 합니다. 예를 들어, 통근자들은 교통 정체와 우회로로 인한 불편을 겪고 있을 때는 인터체인지 공사에 대해 극도로 낮은 평가를 내릴 수 있습니다. 나중에 인터체인지가 완공되어 교통이 그 어느 때보다 빠르게 흐르게 되면, 그들은 프로젝트의 전반적인 성공을 매우 높이 평가할 가능성이 큽니다. 소비자 제품 분야에서 새로운 무선 기기를 찾는 고객은 사용 편의성과 신뢰성을 기준으로 프로젝트 성공을 판단할 수 있는 반면, 그 기기를 생산하는 회사는 판매 대수를 기준으로 프로젝트 성공을 평가할 수 있습니다. 한편, 업계 전체는 그 프로젝트가 새로운 기술 표준을 확립할 경우에만 성공으로 평가할 수도 있습니다.

관점을 만드는 단계에만 한정하면 "프로젝트 결과"와 "프로젝트 성공"이라는 용어가 같은 뜻이라고 생각하기 쉽습니다. 예를 들어, 여러분이 LEED(Leadership in Energy & Environmental Design) 기준에 따라 에너지 효율이 높은 주택을 짓는 일을 맡았다고 가정해 봅시다. 만드는 단계가 끝났을 때 여러분의 팀이 명시된 LEED 요소를 모두 갖춘 구조물을 일정과 예산에 맞추어 완성했다면, 여러분은 아마 그 결과를 성공으로 여길 것입니다. 그러나 주택이 운영/사용/변경 단계에 들어서면, 주택의 에너지 사용에 관한 정보로 인해 프로젝트의 성공 또는 실패에 대한 생각이 바뀔 수도 있습니다. 실제로 LEED 요소가 기대한 대로 작동하지 않는다면, 여러분은 아마 프로젝트의 전반적인 성공을 꽤 낮게 평가할 것입니다. 어쩌면 더 중요한 점은, 주택 소유자도 그 주택을 성공작으로 여기지 않을 가능성이 높다는 것입니다. 또한 수명 추정치와 끊임없이 변하는 외부 요인에 따라 주택의 수명 역시 처음 예상과 크게 달라질 수 있습니다.

간단히 말해, 프로젝트 성공은 프로젝트를 잘 수행하고 정해진 목표를 달성하는 것으로 정의됩니다. 프로젝트 결과는 여러분과 여러분의 팀이 옳은 일을 했는지도 포함합니다. 개별 작업, 프로젝트 전체, 그리고 프로젝트가 수명 전반에 걸쳐 미치는 영향이라는 여러 수준에서 이 둘을 모두 고려하는 것이 중요합니다. 어떤 경우든 프로젝트의 성공이나 실패에 기여하는 요인을 폭넓게 생각해야 합니다. 프로젝트 성공을 계획하고 평가할 때 고려하는 범위에 울타리를 너무 좁게 치면 지속적인 가치를 잃을 위험이 있습니다.

지속 가능성과 살아 있는 질서

이상적인 프로젝트 관리자는 완성된 프로젝트를 앞으로 사용하고 수정할 사람들, 나아가 결국 그것을 철거하거나 재활용할 사람들에게까지 공감합니다. 이상적으로 이는 궁극적으로 재활용할 수 있는 자재를 사용한다는 뜻입니다. 실제로 유럽 연합에서는 자동차 제조업체가 폐차(end-of-life vehicle, ELV)에서 발생하는 재활용할 수 없는 폐기물을 5%까지 줄이도록 법으로 규정되어 있습니다. 이러한 사고방식에는 그림 1-5와 같이 제품 수명 주기를 더 복잡하게 바라보는 관점이 필요합니다(Kanari, Pineau and Shallari 2003).

살아 있는 질서의 현실을 인식한 데서 비롯된 지속 가능성 노력이 건설 업계에서 활발히 진행되고 있습니다. 워싱턴의 건축가 랜스 호지(Lance Hosey)가 주장했듯이, 지속 가능한 건축이란 무엇보다도 쉽게 해체할 수 있는 건물을 지어 철거 과정에 따르기 마련인 혼란과 오염을 최소화하는 것을 의미합니다(2005). 소프트웨어 개발자도 예를 들어 오래된 하드웨어에서도 실행되는 코드를 작성함으로써 매립지로 향하는 컴퓨터 장비의 양을 최소화하는 등 지속 가능한 소프트웨어를 개발할 수 있습니다(Green Wiki 2015).

비영리 단체 Business for Social Responsibility가 발간한 보고서 Software Accelerates Sustainable Development에서 논의하듯이, 소프트웨어는 그 자체로 지속 가능하게 설계될 뿐 아니라 다른 지속 가능성 노력을 촉진할 잠재력도 지니고 있습니다(2008). UW-Madison의 애플리케이션 개발 및 통합 책임자인 데이비드 페이겐코프(David Pagenkopf)는 지속 가능성과 소프트웨어 설계에 대해 다음과 같이 말합니다.

소비재에는 갈수록 늘어나는 다양한 지속 가능성 요구가 따릅니다. 브라이언 버로(Bryan Burrough)가 뉴욕 타임스에 쓴 바와 같이, 월마트는 “전 생산 라인에 걸쳐 포장 크기를 줄여 연간 약 34억 달러를 절감하는 동시에…쓰레기도 줄였습니다“(Burrough 2011). 10년 넘게 기울인 노력은 “오늘날 실질적인 효과를 내고 있는” 지속 가능성 이니셔티브로 결실을 맺었습니다. “이 회사는 자신의 규모를 전략적으로 활용하여 조직 내부뿐 아니라 외부에서도 변화를 이끌어 냈습니다”(Atamian 2017).

1.5 프로젝트 관리자의 네 가지 역할

그렇다면 변화와 예측 불가능성에 관한 이 모든 이야기는 실제 프로젝트 관리자에게 현실적으로 어떤 의미가 있습니까? 이 책 전반에 걸쳐 우리는 기술 프로젝트 관리와 관련된 일상 업무에서 살아 있는 질서의 현실을 수용하는 방법을 살펴볼 것입니다. 예를 들어, 6단원에서는 현재 상황을 반영하기 위한 정기적인 갱신을 우선시하는 적응적이고 순환적인 형태의 계획인 풀 계획에 대해 이야기할 것입니다. 하지만 지금은 살아 있는 질서의 세계에서 프로젝트 관리를 성공적으로 수행하기 위한 몇 가지 일반 원칙을 이야기해 봅시다.

알렉산더 라우퍼(Alexander Laufer), 에드워드 호프먼(Edward Hoffman), 제프리 러셀(Jeffrey Russell), 스콧 캐머런(Scott Cameron)은 MIT Sloan Management Review에 기고한 글에서, 성공적인 프로젝트 관리자들이 더 나은 성과를 얻기 위해 전통적인 관리 방법과 더 새롭고 유연한 접근 방식을 어떻게 결합하는지 보여 줍니다(2015). 이들의 연구에 따르면 성공적인 프로젝트 관리자들은 다음 네 가지 핵심 역할을 수행합니다.

1. 프로젝트 참여자 간의 협업을 발전시킵니다: “대부분의 프로젝트에는 본질적인 부조화가 있습니다. 프로젝트의 여러 당사자는 느슨하게 결합되어 있는 반면, 작업 자체는 긴밀하게 결합되어 있습니다. 예상치 못한 사건이 한 작업에 영향을 미치면, 서로 의존하는 다른 많은 작업도 금세 영향을 받습니다. 그러나 이러한 작업에 대한 직접적인 책임은 느슨하게 결합된 여러 당사자에게 분산되어 있어, 이들은 행동을 조율하거나 적시에 대응하지 못합니다. 따라서 프로젝트 성공에는 다양한 당사자 간의 상호 의존과 신뢰가 모두 필요합니다”(Laufer et al. 2015, 46).
2. 계획 수립과 학습을 통합합니다: “예상치 못한 사건에 직면한 프로젝트 관리자는 계획 수립에 ‘연동 계획(rolling wave)’ 방식을 사용합니다. 이들은 변동성이 큰 정보를 바탕으로는 확고한 약속을 할 수 없다는 점을 인식하고, 프로젝트가 전개되고 정보가 더 신뢰할 만해짐에 따라 계획을 단계적으로 수립합니다. 이들은 팀과 함께 확고한 약속을 담은 상세한 단기 계획을 수립하는 동시에, 세부 사항이 적은 잠정적인 장기 계획도 준비합니다”(Laufer et al. 2015, 46).
3. 큰 혼란을 예방합니다: 성공적인 프로젝트 관리자는 “프로젝트 기간 중 대대적인 시정 조치를 단행하는 일은 몇 번에 불과할지라도, 돌발 상황에 대한 경계를 결코 늦추지 않습니다. 이들은 끊임없이 혼란을 예상하며 선제적으로 대응할 수 있는 유연성을 유지합니다…. 변화가 불가피할 때 성공적인 프로젝트 관리자는 가능한 한 일찍 행동합니다. 위협이 완전히 커지기 전에 대처하는 편이 더 쉽기 때문입니다”(Laufer et al. 2015, 47).
4. 전진하는 추진력을 유지합니다: “예상치 못한 사건이 한 작업에 영향을 미치면, 서로 의존하는 다른 많은 작업도 금세 영향을 받을 수 있습니다. 따라서 문제가 나타나는 즉시 해결하는 것은 작업 진행을 유지하는 데 매우 중요합니다”(Laufer et al. 2015, 48).

이 네 가지 역할을 수행하면 더 적은 낭비로 프로젝트에서 더 많은 가치를 제공하는 길에 들어서게 되며, 이는 린 프로젝트 관리와 애자일 프로젝트 관리 모두의 목표이기도 합니다.

1.6 린: 살아 있는 질서에서 낭비 없애기

예측적인 기하학적 질서의 프로젝트 관리는 비효율적인 경우가 많아 시간, 돈, 자원, 노동력의 낭비로 이어집니다. 이와 대조적으로 린은 예상치 못한 사건에 대처하는 데 필요한 유연성을 허용하면서도 프로젝트를 간소화하는 수단을 제공하는 비즈니스 모델이자 프로젝트 관리 철학입니다. 제2차 세계대전 이후 도요타에서 개발된 아이디어와 관행에 기반한 린은, 프로젝트의 한 단계에서 다음 단계로 작업이 효율적으로 흐르게 하여 낭비를 없애는 동시에 고객을 위한 가치 창출을 강조합니다.

무엇보다도 린은 하나의 사고방식입니다. 제임스 P. 워맥(James P. Womack)과 대니얼 T. 존스(Daniel T. Jones)는 이 주제에 관한 필독서에서 린 사고를 다음과 같이 설명합니다.

이 책 전반에 걸쳐 린에 대해 폭넓게 논의할 것입니다. 우선 여기서는 린의 두 가지 기본 개념인 가치와 낭비에 초점을 맞추겠습니다.

가치

일상적인 대화에서 '가치'는 어떤 것의 전반적인 값어치나 유용성을 가리키는 일반적인 용어입니다. 그러나 린에서 가치는 "특정 시점에 특정 가격으로 고객의 요구를 충족하는 특정 제품(재화나 서비스, 그리고 흔히 둘 다)의 관점에서 표현될 때"에만 의미가 있습니다(Womack and Jones, 16). 다시 말해, 가치는 제조업체나 도급업체, 서비스 제공자가 아니라 고객이 정의하는 것이며, 제품 설계를 책임지는 엔지니어가 정의하는 것은 더더욱 아닙니다.

간단하게 들리지만, 뛰어난 기술 전문성을 갖춘 엔지니어들에게는 받아들이기 어려운 개념일 수 있습니다. Womack과 Jones는 저서에서 포르쉐에 관한 장을 하나 할애하는데, 포르쉐는 1980년대 중반 매출 급락을 겪었으며, 그 주된 원인은 세계적 수준의 엔지니어들이 고객이 정의하는 가치를 보지 못했기 때문이었습니다.

이는 회사가 고객을 위해 생산하고 있다고 여기는 가치에 대한 이해를 왜곡할 수 있는 선입견의 한 가지 예에 불과합니다. Womack과 Jones는 회사가 고객이 실제로 원하는 것을 이해하지 못하게 만드는 요인들을 상세히 다룬 심층 사례 연구를 제시합니다.

린 사고로 도약하려면 가치의 본질을 완전히 이해해야 하며, 이 때문에 이 책 전반에 걸쳐 이 개념을 다시 다룰 것입니다. 또한 그 반대 개념인 낭비도 이해해야 합니다. 린의 궁극적인 목표는 가치를 극대화하고 낭비를 제거하는 것입니다.

낭비

린 용어집(Lean Lexicon)에 따르면, 낭비^[1]란 "자원을 소비하지만 고객에게 아무런 가치도 창출하지 않는 모든 활동"입니다(린 엔터프라이즈 인스티튜트(Lean Enterprise Institute) 2014). 린을 새로 접하는 사람에게는 낭비를 식별하는 것이 가치를 식별하는 것만큼 어려울 수 있습니다.

오늘날 우리가 린이라고 부르는, 낭비와 가치에 초점을 맞추는 방식을 개척한 도요타의 임원 오노 다이이치는 일곱 가지 형태의 낭비를 규명했습니다. 일곱 가지 낭비에 대한 설명은 수많은 책과 기사에서 찾아볼 수 있습니다. 다음 내용은 린 제조 도구(Lean Manufacturing Tools)의 “7가지 낭비"- 를 각색한 것입니다.:

• 운반: 사람, 기계 또는 자재를 실제로 필요한 것보다 더 멀리 옮기는 것입니다. 운반 낭비의 상당 부분은 몇 가지 원인만 꼽더라도 부실한 공장 배치, 큰 배치 크기, 멀리 떨어진 보관 장소 때문에 발생합니다.
• 재고: 예를 들어 부실한 계획이나 기계를 한 공정에서 다른 공정으로 전환하는 데 필요한 시간 때문에 재고가 쌓이는 것입니다.
• 동작: 제품이나 서비스의 가치를 높이지 않는 사람이나 장비의 모든 움직임입니다. 잘못 설계된 작업대나 제대로 정리되지 않은 보관 구역 때문에 몸을 굽히거나 손을 뻗어야 하는 동작이 그 예입니다.
• 대기: 사람이나 기계가 놀고 있는 상태입니다. 무엇보다도 긴 전환 시간, 제대로 조율되지 않은 공정, 결함 있는 부품을 재작업해야 하는 상황 등으로 인해 발생할 수 있습니다.
• 과잉 생산: 합리적인 기간 안에 사용하거나 판매할 수 있는 것보다 더 많이 만드는 것입니다. 이것은 가장 나쁜 형태의 낭비로 여겨지는데, "프로세스 내의 다른 모든 문제를 가리기" 때문입니다(린 매뉴팩처링 툴스(Lean Manufacturing Tools) n.d.). 이 책의 뒷부분에서는 풀 계획과 같은 린 기법을 통해 이러한 형태의 낭비를 피하는 방법을 다룰 것입니다.
• 과잉 처리: 고객의 관점에서 유용하거나 필요한 것 이상을 하는 것입니다. Womack과 Jones가 설명한 포르쉐의 과잉 설계는 과잉 처리의 명확한 사례입니다. 좀 더 일상적인 예로는 고객이 실제로는 국산 모차렐라를 더 좋아하는데도 피자에 값비싼 수입 치즈를 사용하는 식당을 들 수 있습니다.
• 결함: 결함 있는 부품이나 제대로 제공되지 않은 서비스를 바로잡는 데 필요한 시간과 노력입니다. 대부분의 사람들은 낭비를 찾아보라고 하면 이것을 떠올립니다. 그러나 결함과 관련된 비용을 정확하게 가늠하기는 어려울 수 있습니다. 이러한 비용에는 "문제 해결, 자재, 재작업, 자재 일정 재조정, 설비 준비, 운송, 서류 작업, 리드 타임 증가, 납품 실패, 그리고 잠재적인 고객 상실과 관련된 비용"이 포함될 수 있습니다(린 매뉴팩처링 툴스(Lean Manufacturing Tools)).

낭비를 생각하는 또 다른 방법은 그것을 얼마나 쉽게 제거할 수 있는지에 초점을 맞추는 것입니다. 그렇게 보면 낭비는 두 가지 유형으로 나뉩니다.

• 제1유형 낭비: "가치를 창출하지 않지만 현재의 기술과 생산 자산으로는 피할 수 없는" 낭비입니다(린 엔터프라이즈 인스티튜트(Lean Enterprise Institute) 2014). 이런 종류의 낭비는 필요하지만 향후에는 제거될 수도 있습니다. 제1유형 낭비의 예로는 특정 부품이 정부 안전 기준을 충족하는지 확인하는 데 필요한 정기 검사를 들 수 있습니다. 이러한 검사는 필요하기는 하지만 고객의 관점에서는 실제로 가치를 제공하지 않으며, 해당 부품 자체가 기기에서 제거되거나 재설계된다면 없앨 수도 있을 것입니다.
• 제2유형 낭비: 가치를 창출하지 않으며 즉시 제거할 수 있는 낭비입니다. 예를 들어 새로 만든 전자레인지를 포장 기계까지 운반하는 데 드는 시간과 노력은 포장 기계를 옮김으로써 제거할 수 있는 낭비입니다.

프로젝트 관리에서 제1유형 낭비의 예로는 계약된 작업이나 약속된 제품의 성과를 합의된 요구 사항에 비추어 측정하는 데 필요한 감사를 들 수 있습니다. 고객의 관점에서 이러한 감사는 아무런 가치를 더하지 않지만, 프로젝트를 성공적으로 완료하기 위해서는 필요합니다. 프로젝트 관리에서 흔히 볼 수 있는 제2유형 낭비는 끊임없는 진행 상황 보고 요청입니다. 아직 팀과 신뢰를 쌓지 못한 신임 프로젝트 관리자는 모든 작업을 세세하게 관리하려다가 이러한 형태의 낭비에 빠지기도 합니다. 정기적으로 예정된 진행 상황 보고와 예상치 못한 문제에 대한 에스컬레이션 기준을 마련하면 프로젝트 관리에서 이러한 제2유형 낭비를 없애는 데 도움이 됩니다.

린의 여섯 가지 원칙

린 사고의 핵심을 이루는 여섯 가지 원칙은 가치 명시, 가치 흐름 파악, 흐름, 풀, 완벽 추구, 사람 존중입니다. 이 책 전반에 걸쳐 이러한 개념과 이 개념이 기술 프로젝트 관리와 어떤 관련이 있는지 더 자세히 배우게 됩니다. 여기서는 앞으로 학습의 토대가 될 수 있도록 각 개념을 간략히 설명하겠습니다. 이 단원의 사례는 대부분 린이 처음 시작된 제조업에서 가져왔습니다. 그러나 린 사고는 건설업이나 의료 산업처럼 다양한 산업에서 널리 채택되어 왔다는 점을 기억하십시오.

1. 1. 가치 파악: 앞서 설명했듯이 가치는 오직 고객만이 정의할 수 있습니다. 프로젝트 관리자는 먼저 그 정의가 무엇인지 알아내는 것부터 시작해야 하며, 가장 좋은 방법은 고객과 직접 대화하는 것입니다. 그러나 고객이 “이미 받고 있는 것의 변형을 요청하는 방법밖에 모른다”는 사실을 알게 될 수도 있습니다(Womack and Jones 2003, 31). 따라서 가치를 파악하려면 스스로 가치를 충분히 생각해 볼 기회가 없었을지도 모르는 고객에게서 가치의 정의를 이끌어 내도록 고안된 심층적인 질문을 던져야 하는 경우가 많습니다. 대개 처음 던지기에 가장 좋은 질문은 다음과 같습니다. 어떤 문제를 해결하고 싶으십니까? 성공한 모습은 어떤 모습입니까?
   2. 가치 흐름 매핑: 가치 흐름이란 “제품을 개념 단계에서부터” 인도에 이르기까지 “필요한, 가치를 창출하는 활동과 가치를 창출하지 않는 활동을 모두 포함한 모든 활동”입니다(린 기업 연구소(Lean Enterprise Institute) 2014). 어떤 산업이든 가치 흐름에 속한 활동의 대다수는 아무런 가치도 창출하지 않으므로 낭비입니다. 특정 제품의 가치 흐름을 분석하려는 기업은 일반적으로 제품을 시장에 내놓는 데 관련된 모든 것을 고려하면서 자사 사업장을 훨씬 넘어서는 범위까지 살펴보아야 합니다. 예를 들어, 새로운 종류의 빵에 대한 가치 흐름은 네브래스카의 밀 농장에 물을 대는 데 쓰이는 지하수에서 시작될 수도 있습니다. 프로젝트 관리의 관점에서 가치 흐름을 살펴볼 때, 목표는 착수, 계획, 실행, 모니터링 및 통제, 종료를 포함하여 프로젝트의 모든 측면을 이해하는 것입니다.

      배치 앤 큐: 연속 흐름의 반대

      제과점에서 생일 케이크 100개를 굽고, 프로스팅을 바르고, 장식하고, 상자에 담는 작업을 위해 배치 앤 큐 시스템을 구축한다고 가정해 봅시다. 케이크를 구우면서 프로스팅을 바를 준비가 될 때까지 케이크가 신선하게 유지되도록 적절한 보관 방법을 마련해야 합니다. 모든 케이크에 프로스팅을 바르고 장식 단계로 넘어간 뒤에야 장식이 프로스팅에 붙지 않는다는 사실을 알게 될 수도 있습니다. 케이크 하나만 먼저 굽고, 프로스팅을 바르고, 장식해 보았다면 이 문제가 모든 케이크에 영향을 미치는 결함이 되기 전에 발견하고 해결했을 것입니다. 그러나 이미 모든 케이크를 굽고 프로스팅까지 발랐기 때문에, 이제는 케이크에 이미 발라 둔 프로스팅에 붙는 새 장식을 사야 하는 처지가 됩니다. 상자에서도 비슷한 문제가 생길 수 있습니다. 프로스팅과 장식을 마친 케이크 100개를 상자에 담을 준비를 해 두었는데, 주문한 상자에 케이크가 들어가지 않는다는 사실을 발견할 수도 있습니다. 그동안 케이크는 점점 굳어 가고, 머지않아 팔 수 없는 상태가 될 수도 있습니다.

   3. 연속 흐름: Womack과 Jones에 따르면, 대부분의 사람들은 여러 단계로 이루어진 프로젝트를 완료하는 가장 효율적인 방법이 작업을 배치로 나누는 것, 즉 사용 가능한 모든 자재에 첫 번째 단계를 수행하고 모든 자재가 처리될 때까지 그 결과물을 따로 보관해 두는 것이라고 생각하는 경향이 있습니다. 배치 전체가 완료되면 다음 단계로 넘어가 다시 배치 전체를 처리하고, 이런 식으로 모든 단계를 거쳐 나갑니다. 배치 앤 큐(batch and queue)라고 알려진 이 방식은 많은 상황에서 유용할 수 있지만, 매우 비효율적인 경우가 많고, 공정이 여러 단계 진행된 뒤에야 발견되는 결함으로 이어질 수 있습니다(Womack and Jones 2003, 22). 린은 배치 앤 큐 생산에 따르는 문제를 피하기 위해, 다음 단계의 작업자가 즉시 처리할 수 있는 작은 배치로 한 단계에서 다음 단계로 이어지는 연속 흐름을 강조합니다. 생산 시간을 극적으로 단축하는 진정한 연속 흐름은 가치를 창출하지 않는 단계라는 낭비를 제거한 다음, 남은 단계들이 차례로 이어지도록 재배치한 후에야 비로소 가능합니다. 모든 산업에서 현실적인 목표는 아니지만, 기계를 옮기고 인력을 재배치함으로써 흐름의 이점을 어느 정도 얻을 수 있는 경우가 많습니다. 프로젝트 관리에서는 일정을 수립할 때 흐름이 문제가 될 수 있습니다. 예를 들어, 프로젝트 팀은 지나치게 잘게 쪼갠 시간 단위로 불필요하게 상세한 일정을 짜느라 애쓰며, 여러 해에 걸친 프로젝트의 작업을 시간 단위로 계획하는 실수를 저지를 수 있습니다. 그런 다음, 비현실적인 일정에 이 모든 시간을 낭비한 뒤, 팀은 프로젝트가 진행되는 동안 실제 진척 상황을 검토하고 갱신하지 못할 수도 있습니다. 이러한 흐름의 부재는 프로젝트의 전반적인 성공에 실질적인 위험을 초래할 수 있습니다. 이와 대조적으로, 린 사고방식을 갖춘 프로젝트 관리자는 일정이 살아 있는 문서이며, 프로젝트 전반에 걸쳐 살아 있는 질서의 변화(긍정적인 변화와 부정적인 변화 모두)에 대응해야 한다는 것을 이해하고, 이를 통해 프로젝트의 전 생애에 걸쳐 진정한 흐름을 가능하게 합니다.
   4. 풀: 풀의 의미를 이해하려면 먼저 푸시의 의미를 이해해야 합니다. 전통적인 생산 시스템은 푸시 시스템으로 간주되며, 작업은 생산 일정에 따라 정해지는데, 이 일정은 때로는 고객 수요에 대한 정확한 예측과 연결되어 있지만 그렇지 않은 경우가 많습니다. 푸시 시스템은 과잉 생산이라는 낭비로 이어지기 쉽습니다. 마크 그래번은 다음과 같은 몇 가지 예를 제시합니다.
      • 음식을 만들어 보온 램프 아래에 보관하는 패스트푸드 식당(그중 일부는 버려집니다).
      • 승용차나 트럭을 과도하게 생산하고 대리점에 이를 떠안도록 강요하는 자동차 제조업체.
      • 미국 조폐국이 고객 수요를 훨씬 초과하는 달러 주화를 생산하는 것.
      • 제품을 만들어 소매점에 출하하지만 진열대에 그대로 놓여 있게 되는 컴퓨터 제조업체. (2014)

      이와 대조적으로, 풀 시스템은 실제 고객 수요에 따라 제품을 만들고 자재를 소비합니다. 이는 샌드위치 가게가 주문을 받은 후에 여러분이 좋아하는 칠면조 과카몰리 샌드위치를 만드는 방식과 같습니다. 실제로 대부분의 시스템은 풀 생산과 푸시 생산을 조합하여 사용합니다. 예를 들어, 그 자리에서 샌드위치를 만드는 것은 풀 활동이지만, 가게는 아마도 고객 수요 예측에 따라 칠면조와 과카몰리를 미리 주문함으로써 푸시 생산을 실행했을 것입니다.

      이러한 예는 린의 풀 개념을 크게 단순화한 것입니다. 실제로는, 특히 거대한 공장이나 건설 현장에서는 훨씬 더 복잡합니다. 그러나 낭비를 줄이는 기본 원칙은 언제나 같습니다. "하류의 고객이 요청하기 전까지 상류의 누구도 재화나 서비스를 생산해서는 안 됩니다"(Womack and Jones 2003, 67).

      이 훌륭한 블로그 게시물은 매점 사례를 통해, 풀 시스템이 소량의 재료만 보유하고 사용한 만큼 보충함으로써 재고 낭비와 과잉 생산 낭비를 피하는 방식을 보여 줍니다:
      린 블리츠 컨설팅(Lean Blitz Consulting) – “도요타 방식 원칙 #3: “풀” 시스템”

      풀(pull)의 개념을 프로젝트 관리에 적용하기는 어려울 수 있지만, 그렇게 하면 강력한 결과를 얻을 수 있습니다. 팀은 끝점, 즉 프로젝트의 최종 목표에서 출발하여 활동을 앞으로 당겨 오면서 각 단계마다 무엇을 해야 하는지 기술합니다. 이는 표준적인 프로젝트 관리와 크게 다릅니다. 표준적인 프로젝트 관리는 처음부터 시작하여, 팀이 다음 작업에 착수하기 전에 이전 작업이 완전히 끝난다고 가정하는 일정을 수립합니다. 반면 린 일정에서는 더 많은 작업이 서로 겹칩니다. 칸반은 풀을 비롯한 린 개념에 기반한 적응형 프로젝트 관리 방법론입니다. 칸반에 대해서는 이 단원의 뒷부분에서 더 자세히 다루겠습니다.

      크리스틴 엥겔(Kristine Engel)은 송전선 설계를 위한 프로젝트 계획에 관한 발표에서, 풀 일정에서는 "'나중 작업'이 '앞선' 작업이 끝나기 전에 시작될 수 있으며", 일부 "설계 개선 작업은 노무 입찰 과정이나 심지어 시공과도 겹칠 수 있는데, 이는 유틸리티 프로젝트의 현실을 반영한 것"이라고 설명합니다. 이처럼 유동적임에도 불구하고 팀은 청구 시간을 예산과 비교하여 진척 상황을 추적할 수 있습니다. 시스템 전체는 "전체 프로젝트 일정에 맞추어 단기 목표를 수정하기 위한 고객과의 정기적인 소통" 위에 구축됩니다(Engel 2017).

   5. 완벽 추구: 숙련된 린 실무자들은 고객이 정의하는 가치를 더 잘 파악하게 될수록 가치 흐름의 모든 단계를 더 정확하게 파악하게 된다고 증언합니다. 그 결과 가치를 더하지 않는 활동이라는 낭비를 줄이게 되고, 이를 통해 흐름이 개선됩니다. 경험이 쌓이면 어디에서나 린 방식으로 개선할 기회가 보이기 시작할 것입니다. 이는 역기 들기와 같습니다. 많이 들수록 더 많이 들 수 있게 됩니다. 낭비를 많이 제거할수록 더 많은 낭비를 제거할 수 있게 됩니다. Jones와 Womack에 따르면, 이러한 현상은 처음 네 가지 원칙이 선순환 속에서 서로 상호 작용하기 때문에 일어납니다. 가치가 더 빨리 흐르게 하면 가치 흐름 속에 숨어 있던 무다[낭비]가 언제나 드러납니다. 그리고 더 강하게 당길수록 흐름을 가로막는 장애물이 더 많이 드러나므로 이를 제거할 수 있습니다. 고객과 직접 대화하는 전담 제품 팀은 언제나 가치를 더 정확하게 명시하는 방법을 찾아내며, 흐름과 풀을 강화하는 방법도 자주 알게 됩니다. (2003, 25)
   6. 사람에 대한 존중: 무엇보다도 린은 모든 이해관계자 간의 끊임없는 소통을 요구합니다. 린의 처음 다섯 가지 원칙을 실행하는 것은 모든 팀원이 서로 존중하고 귀 기울이며, 아이디어를 공유하고, 제안을 받아들이고, 협력하여 문제를 해결하고 낭비를 제거할 때에만 가능합니다. 사람에 대한 존중이란 친절하게 대하는 것이 아니라, 혼자서는 문제를 해결할 수 없으며 그 대신 동료들과 진심으로 정직하게 관계를 맺어야 한다는 점을 이해하는 것입니다. 때로는 동료에게 이의를 제기하고 비판을 제시하는 것을 의미하기도 합니다. 그리고 언제나 자신이 틀렸을 때 기꺼이 인정하는 것을 의미합니다.

1.7 애자일: 살아 있는 질서 속의 빠른 피드백

린은 원래 제조업 분야에서 개발되었지만 많은 산업에서 채택되었습니다. 소프트웨어 개발 분야에서는 이와 관련된 접근 방식인 애자일이 점점 더 인기를 얻고 있습니다. 애자일 소프트웨어 개발 프로젝트에는 일반적으로 짧은 반복 주기로 협업하며 작동하는 제품 증분을 만들어 내는 소규모 자기 조직화 팀이 참여합니다. 사람들이 애자일에 대해 이야기할 때는 일하는 방식을 지속적으로 조정하고 개선함으로써 프로젝트 팀이 "민첩성을 달성"하도록 이끄는 일련의 가치와 원칙을 포괄적으로 가리키는 것일 수 있습니다. 그러나 사람들은 애자일이라는 용어를 그러한 가치와 원칙에 기반한 여러 구체적인 소프트웨어 개발 프레임워크 중 하나를 가리키는 데 사용하는 경우가 많으며, 그 예는 다음과 같습니다.

애자일의 다양한 형태는 다음과 같습니다.

• 스크럼: 소규모의 교차 기능적인 자기 조직화 팀을 활용하여 복잡한 프로젝트를 완수하도록 설계된 스크럼은(ScrumGuides에 설명된 바와 같이) 가장 널리 사용되는 애자일 형태입니다. 사람들이 "애자일 소프트웨어 개발"이라고 말할 때는 보통 스크럼 실천 방식을 이야기하는 것이며, 이 전자책에서도 흔히 그러한 의미로 사용합니다.
• 칸반: 린 원칙에 기반한 칸반은 점진적인 변화와 지속적인 프로세스 개선에 중점을 둡니다. 이 단순한 프레임워크의 핵심은 칸반 보드로, 진행 중인 모든 프로젝트 작업, 시작을 기다리는 작업, 이미 완료된 작업을 시각적으로 보여 줍니다. 칸반 프레임워크에 대한 자세한 내용은 다음 글에서 읽을 수 있습니다: "Kanban"
• 익스트림 프로그래밍(XP): 평가를 위해 소프트웨어를 자주 릴리스하는 짧은 개발 주기를 강조하는 XP는 일련의 소프트웨어 개발 모범 사례에 기반합니다. 익스트림 프로그래밍에 대한 자세한 내용은 "Extreme Programming: A Gentle Introduction"에서 읽을 수 있습니다.
• 크리스털, 동적 시스템 개발 방법론(DSDM), 기능 주도 개발(FDD): 이들은 그 밖에 비교적 널리 쓰이는 애자일 프레임워크입니다. 이 목록에 있는 프레임워크와 그 밖의 애자일 프레임워크에 대한 자세한 내용은 "프로젝트 관리 프레임워크"에서 읽을 수 있습니다.

대부분의 애자일 접근 방식은 제품 개발에서 반복적인 접근 방식을 강조하며, 프로젝트 명세는 소프트웨어 요구 사항에 대한 고객의 생각과 함께 발전해 나갑니다. 프로젝트 관리자 스티브 케이슬리(Steve Caseley)는 Microsoft Growth Center의 글에서 이러한 반복적 개발 접근 방식을 사용하는 프로젝트는 "프로젝트 기능을 작은 단위(또는 반복)로 계획하고, 개발하고, 구현합니다. 성공적인 반복적 인도의 핵심은 각각의 작은 단위가 전체 프로젝트라는 우산 아래에서 사실상 더 작은 미니 프로젝트로 운영된다는 점입니다"라고 말합니다(Caseley 2019).

스크럼 프로젝트는 고객이 소프트웨어로 무엇을 하기를 원하는지에 대해 개발 팀과 제품 책임자가 나누는 대화로 시작됩니다. 스크럼 용어로 고객은 제품 책임자이며, 제품 책임자가 소프트웨어에 포함되기를 원하는 기능은 사용자 스토리라고 합니다. 사용자 스토리는 해당 기능을 원하는 사람의 관점에서 간단하고 비기술적인 언어로 표현될 수 있습니다. 예를 들면 "자동차 소유자로서, 정비사에게 전화하느라 시간을 쓰지 않도록 온라인으로 정비 예약 일정을 잡고 싶습니다."와 같습니다. 이때 그 사람은 흔히 특정 유형의 사용자나 이해관계자를 대표하는 가상의 페르소나입니다.

제품 책임자는 통틀어 제품 백로그라고 부르는 사용자 스토리들의 우선순위를 정하고, 팀은 각 개발 주기마다 하나 이상의 사용자 스토리를 다루는 소프트웨어 조각을 만듭니다. 1~2주간의 개발 주기(스크럼에서는 스프린트라고 합니다)가 끝나면 팀은 스프린트 리뷰 회의에서 새 소프트웨어를 제품 책임자에게 시연하며, 제품 책임자는 이를 직접 사용해 보고 개선 사항을 제안할 수 있습니다. 그런 다음 팀은 또 다른 스프린트를 시작하여, 그 제안 사항을 새로운 반복에 반영하고 팀의 역량에 따라 새로운 사용자 스토리 작업에 착수합니다. 매 스프린트가 끝날 때마다 제품 책임자는 팀이 새로운 사용자 스토리로 방향을 전환하도록 하거나, 기존 사용자 스토리에 대한 팀의 이해를 수정할 기회를 갖습니다. 빠르고 집중적인 피드백을 제공하는 이러한 반복적인 상호 작용을 통해, 팀과 제품 책임자는 제품 책임자가 필요로 하는 기능을 수행하는 소프트웨어 애플리케이션에 점점 다가갑니다. 흔히 그렇듯이 시간과 비용이 빠듯한 경우, 제품 책임자는 어떤 사용자 스토리가 가장 중요하고 어떤 사용자 스토리를 필요하다면 생략할 수 있는지 정기적으로 선택할 기회를 갖습니다.

애자일 개발은 본질적으로 개발 팀과 제품 책임자가 주어진 시간과 비용 안에서 얼마나 많은 기능을 만들 수 있는지에 대한 공통의 이해를 형성해 가는 학습 과정입니다. 초기 단계에 어느 정도의 모호함과 많은 미지의 요소가 포함된다는 점에서, 이는 프로젝트 관리에 대한 전형적인 살아 있는 질서의 접근 방식입니다. 위스콘신 대학교 매디슨 캠퍼스의 선임 비즈니스 분석가이자 애자일 코치인 로버트 메릴(Robert Merrill)에 따르면, "애자일은 예측 불가능성과 제약, 흔히 매우 엄격한 시간 및 예산 제약에 직면한 상황에서 프로젝트를 관리하는 방법입니다. 빠른 피드백 덕분에 팀은 주어진 제약 안에서 가능한 최선의 소프트웨어를 만들 수 있습니다"(2017).

일부 기업은 여러 애자일 프레임워크를 조합하여 사용하거나(흔히 하이브리드 애자일이라고 부릅니다), 몇 가지 예측적·계획 주도적 프로세스를 애자일 프레임워크의 요소와 조합하여 사용합니다(하이브리드 개발 접근 방식이라고도 부릅니다). 하이브리드 애자일 프로젝트에는 제품 책임자와 개발 스프린트 같은 전형적인 스크럼 요소뿐만 아니라 수용 능력에 따라 작업을 당겨 오는 데 사용하는 칸반 보드도 포함될 수 있습니다. 하이브리드 개발 접근 방식에는 예측적 프로젝트 계획과 함께 보다 유연한 애자일 개발 주기가 포함될 수 있습니다. 스크럼처럼 엄격한 애자일 접근 방식이든 하이브리드 접근 방식이든, 어떤 접근 방식을 사용할지에 대한 결정은 프로젝트의 요구뿐 아니라 프로젝트가 전개될 조직 환경에 근거해야 합니다.

시각적 프로젝트 관리 소프트웨어 플랫폼 등의 제품을 보유한 회사 PieMatrix의 CEO 폴 댄더던(Paul Dandurdan)은 애자일 접근 방식과 예측적(폭포수) 접근 방식 모두에 가치가 있다고 주장합니다. 그는 블로그 게시물 "하이브리드 애자일 선언문과 스파이더맨"에서 하이브리드 애자일/폭포수 선언문을 제안하며, 자신이 보기에 원래 애자일 선언문이 지닌 한계도 강조합니다.

린과 마찬가지로 애자일도 이 책 전반에 걸쳐 반복적으로 다룰 주제입니다. 애자일에 대해 스스로 공부를 시작하려면 다음 자료를 참고하십시오.

• 2001년에 일단의 소프트웨어 개발자들이 애자일 소프트웨어 개발의 12가지 원칙을 정리한 애자일 선언문을 발표했습니다. 선언문 전문은 다음에서 읽을 수 있습니다: "애자일 선언문 이면의 원칙."
• 애자일에 대한 친절한 소개, 에릭 브루노(Eric Bruno)의 블로그 게시물입니다.
• "애자일 방법론이란 무엇인가?", 5분 분량의 동영상입니다.
• "애자일 제품 소유권 요약", 소프트웨어 개발에 관한 15분 51초 분량의 동영상입니다.

실용적인 팁

• 시간을 들여 프로젝트의 고유하고 변화하는 맥락을 파악하십시오: 프로젝트의 맥락, 즉 프로젝트가 전개되는 일상적인 환경과 더 넓은 조직적 배경은 프로젝트마다 같은 경우가 드물며, 프로젝트가 진행되는 동안에도 바뀔 수 있습니다. 각 프로젝트의 고유한 맥락과 그것이 바뀔 수 있는 여러 방식을 파악하면, 나중에 틀린 것으로 드러날 수 있는 가정을 세울 가능성을 줄일 수 있습니다. 이러한 고려 사항은 특정 프로젝트에 어떤 프로젝트 관리 방식을 사용할지 결정하는 데에도 도움이 됩니다. 애자일 프로젝트 관리 방법론을 도입하기 전에, 조직 문화가 애자일의 가치 및 원칙과 어느 정도 부합하는지 평가하십시오. 보다 전통적인 조직 안에서 애자일 또는 하이브리드 애자일 방식을 도입하려면, 인내심을 가지고 살아 있는 질서 속에서 일할 때 얻는 이점을 적극적으로 알려야 할 수 있습니다.
• 기존 프로젝트에 합류하는 경우, 팀 문화에 대해 최대한 많이 파악하고 그에 맞게 당장의 기대치를 설정하십시오: 먼저 프로젝트의 문화를 인식하고, 가능하다면 그 문화에 동화되어 자신의 일하는 방식을 조정하십시오. 관계를 쌓아 가며 간접적인 영향력을 발휘하여 프로젝트 문화를 형성하십시오.
• 기하학적 질서와 살아 있는 질서의 기법을 모두 사용할 준비를 하십시오: 프로젝트는 일이 예측 가능하게 전개될 것이라는 순진한 가정 아래 기하학적 질서 속에서 구상되고 계획되는 경우가 많습니다. 그러다 현실에 부딪히면, 프로젝트는 살아 있는 질서의 불확실성 한가운데에서 실행됩니다. 그러나 프로젝트가 전개되면서 무엇을 예상해야 할지 알게 되면, 결국 프로젝트는 더 기하학적인 성격을 띠게 될 수 있습니다. 필요에 따라 상황에 적응하면서 기하학적 질서의 기법과 살아 있는 질서의 기법 사이를 오갈 준비를 하십시오.
• 기하학적 질서 속에서 일할 때는 다음 사항에 집중하십시오:
  • 프로젝트 성공을 정의하십시오.
  • 프로젝트 일정표를 수립하십시오.
  • 프로젝트가 명시된 결과를 산출하도록 하십시오.
  • 프로젝트 일정과 비교하여 진행 상황을 지속적으로 확인하십시오.
  • 프로젝트 예산과 비교하여 비용을 정기적으로 확인하십시오.
  • 주기적으로 잠시 멈춰서, 프로젝트가 실제로 기하학적 질서 속에서 전개되고 있으며 살아 있는 질서로 바뀌지 않았는지 확인하십시오.
• 살아 있는 질서 속에서 일할 때는 적절한 경우 좋은 기하학적 관행을 따르되, 다음 사항에도 집중하십시오:
  • 모든 이해관계자가 프로젝트의 공유 가치를 이해하고 이를 달성하는 데 전념하도록 하십시오.
  • 프로젝트 이해관계자가 프로젝트의 모든 단계에서 무슨 일이 일어나고 있는지 이해할 수 있도록 유용한 모든 형태의 의사소통을 활용하십시오.
  • 가치를 창출하는 활동에 집중하고 낭비적인 활동은 없애십시오.
  • 애자일하고 적응력 있는 태도를 유지하면서 변화하는 상황에 대응할 준비를 하십시오.

~요약

• 프로젝트는 유연하고 적응력 있는 접근 방식이 필요한 고유하고 변화하는 맥락 속에서 전개됩니다.
• 프로젝트는 수많은 내부 및 외부 요인의 영향을 받습니다. 그러한 요인 중 하나인 문화는 프로젝트의 맥락과 결과에 지대한 영향을 미칠 수 있습니다. 동일한 도구, 계약, 구조를 사용하는 프로젝트라도 프로젝트 팀과 조직의 문화에 따라 결과가 크게 달라질 수 있습니다.
• 조직은 흔히 살아 있는 질서의 예측할 수 없는 격변 속에서 프로젝트를 구상한 다음, 모든 단계를 마지막 세부 사항까지 계획하면서 보다 체계적인 기하학적 질서 속에서 이를 실행하려 합니다. 성공적인 프로젝트 관리자는 프로젝트가 실제로 전개되는 예측 불가능한 끝없는 급류의 세계를 결코 놓치지 않습니다.
• 프로젝트의 생애 주기에는 단순히 만드는 단계 이상의 것이 포함된다는 점을 이해하면 "프로젝트 성공"에 대한 이해가 넓어질 것입니다.
• 린 프로젝트 관리는 가치를 극대화하고 낭비를 제거하는 데 중점을 둡니다.
• 애자일 가치와 원칙에 기반한 프로젝트 관리 프레임워크는 살아 있는 질서에서 요구되는 유연성을 장려합니다. 하이브리드 애자일 접근법과 하이브리드 개발 접근법은 하나 이상의 애자일 프레임워크의 특징을 결합하며, 때로는 보다 전통적인 폭포수 접근법의 요소와 함께 결합하기도 합니다.

용어집

• 애자일—프로젝트 팀이 일하는 방식을 지속적으로 조정하고 개선함으로써 "민첩성을 달성"하도록 이끌기 위한 일련의 가치와 원칙입니다. 또한 때로는 이러한 가치와 원칙에 기반한 소프트웨어 개발 프레임워크 및 방법론 중 하나를 가리키는 데 사용되기도 합니다. 애자일 접근법은 제품 개발에 대한 반복적 접근을 강조하며, 프로젝트 명세는 소프트웨어 요구 사항에 대한 고객의 생각과 함께 발전합니다. 널리 사용되는 애자일 프레임워크와 방법론으로는 스크럼, 칸반, 익스트림 프로그래밍(XP)이 있습니다.
• 행동 경제학—OxfordDictionaries.com에 따르면 "인간 행동에 대한 심리학적 통찰을 적용하여 경제적 의사 결정을 설명하는 경제 분석 방법"입니다.
• 기하학적 질서—프랑스 철학자 Henri Bergson이 규명한 질서의 한 유형으로, 선형적인 전개, 명확한 인과 관계, 예측 가능한 사건이 특징입니다.
• 하이브리드 애자일— 애자일 프레임워크들의 조합입니다. 예를 들어 스크럼 스프린트와 제품 책임자를 칸반 보드와 함께 사용하는 방식이 이에 해당합니다.
• 통합 프로젝트 발주(IPD)—긴밀한 협업을 강조하는 방식으로 건설 프로젝트의 이해관계자들을 계약상으로 결속시키는 수단으로, 고객이 정의한 가치를 전달하는 것을 목표로 합니다. IPD는 린에서 영감을 받았으며, 프로젝트에서 각 참여자의 역할을 설명하는 다자간 계약이라는 계약 유형에 기반합니다.
• 린—예상치 못한 사건에 대처하는 데 필요한 유연성을 허용하면서도 프로젝트를 간소화하는 수단을 제공하는 비즈니스 모델이자 프로젝트 관리 철학입니다. 린은 프로젝트의 한 단계에서 다음 단계로 이어지는 효율적인 작업 흐름을 통해 낭비를 제거하는 것을 강조합니다.
• 살아 있는 질서—프랑스 철학자 Henri Bergson이 규명한 질서의 한 유형으로, 급격한 변화와 예측 불가능한 사건이 특징입니다.
• 조직 문화–조직을 구성하는 행동, 가치, 산물, 보상 체계, 의례의 총체입니다.
• 프로젝트—"일정 기간에 걸쳐 완료되며 특정한 목적을 달성하기 위해 계획된 작업 또는 활동"입니다(Cambridge English Dictionary 2018).
• 프로젝트 문화—프로젝트에 참여하는 개인들과 독립적으로 존재하는 일련의 신념, 태도, 행동입니다.
  프로젝트 결과—가장 좁은 의미로는 프로젝트의 측정 가능한 산출물을 말하며, 그것이 건물이든 소프트웨어 애플리케이션이든 전투기 부품이든 마찬가지입니다. 더 넓은 의미로는 프로젝트가 더 큰 목표에 비추어 미치는 영향을 말합니다.
• 프로젝트 성공—프로젝트가 잘 수행된 정도입니다. 이해관계자들의 프로젝트 성공 평가는 주관적인 판단으로서 각자의 관점에 따라 달라지며, 일반적으로 시간이 지남에 따라 변화합니다.
• 프로젝트 관리—"프로젝트 목표를 달성하기 위해 프로세스, 방법, 지식, 기술, 경험을 적용하는 것"입니다(Association for Project Management 2018).
• 스프린트—스크럼에서 소프트웨어 개발의 짧은 주기(대개 1주 또는 2주)입니다.
• 사용자 스토리—제품 책임자가 개발 중인 소프트웨어에 포함되기를 원하는 기능입니다. 해당 기능을 원하는 사람의 관점에서 간단하고 비기술적인 언어로 표현될 수 있습니다. 예를 들면 "자동차 소유자로서, 정비사에게 전화하느라 시간을 쓰지 않도록 온라인으로 정비 예약 일정을 잡고 싶습니다."와 같습니다.
• 가치—일상적인 대화에서는 어떤 것의 전반적인 가치나 유용성을 가리키는 일반적인 용어입니다. 그러나 린에서 가치는 "특정 시점에 특정 가격으로 고객의 필요를 충족하는 특정 제품(재화나 서비스, 그리고 흔히 둘 다)의 관점에서 표현될 때"에만 의미가 있습니다(Womack and Jones 2003, 16). 다시 말해, 가치는 고객이 정의합니다.

추가 자원

• The Guide to Lean Enablers for Managing Engineering Programs, 프로그램 관리에서의 린에 관한 MIT·PMI·INCOSE 공동 실천 공동체(Joint MIT PMI INCOSE Community of Practice on Lean in Program Management) 발행(2012).
• Managing as a Performing Art: New Ideas for a World of Chaotic Change, 피터 B. 베일(Peter B. Vaill) 저(1989). 이 책에서 Vaill은 “끝없는 급류”라는 용어를 소개합니다.
• 행동경제학 분야에서의 삶과 연구를 다룬 리처드 탈러(Richard Thaler)의 회고록: Misbehaving: The Making of Behavioral Economics(2015).
• 린에 대한 고전적인 입문서: 도요타 방식: 세계 최고 제조업체의 14가지 경영 원칙, Jeffrey Liker 저(2004).

~참고 문헌

Association for Project Management. n.d. "프로젝트 관리란 무엇입니까?" apm.org. 2018년 6월 15일 접속. https://www.apm.org.uk/resources/what-is-project-management/.

Atamian, Luna. 2017. “Why is Walmart a sustainability leader?” Huffington Post, 12월 14일. https://www.huffingtonpost.com/entry/why-is-walmart-a-sustainability-leader_us_5a329da5e4b00caf3d59eae8.

Bergson, Henri. 1911. “창조적 진화(Creative Evolution).” 프로젝트 구텐베르크(Project Gutenberg). 2018년 6월 15일 접속. http://www.gutenberg.org/files/26163/26163-h/26163-h.htm.

Bersin, Josh. 2015. “Culture: Why It’s the Hottest Topic in Business Today.” Forbes. 3월 13일. https://www.forbes.com/sites/joshbersin/2015/03/13/culture-why-its-the-hottest-topic-in-business-today/#27b6f20f627f.

Bloch, Michael, Sven Blumberg, and Jürgen Laartz. 2012. “대규모 IT 프로젝트를 일정, 예산, 가치에 맞게 완수하기(Delivering Large-Scale IT Projects on Time, on Budget and on Value).” McKinsey&Company. 10월. 2016년 8월 4일 접속. http://www.mckinsey.com/business-functions/business-technology/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value.

Burrough, Bryan. 2011. “Behind the Greening of Wal-Mart.” New York Times, 5월 14일. http://www.nytimes.com/2011/05/15/business/15shelf.html?_r=0.

Business for Social Responsibility. 2008. “Software Accellerates Sustainable Development.” bsr.org. http://www.bsr.org/reports/BSR_Software_Accelerates_Sustainable_Development.pdf.

Cambridge English Dictionary. 2018. “project(프로젝트).” Cambridge Dictionary. 2018년 5월 12일 접속. https://dictionary.cambridge.org/us/dictionary/english/project.

Caseley, Steve. 2019. “프로젝트 관리: 전통적 방식, 반복적 방식, 아니면 하이브리드?(Project Management: Traditional, Iterative, or Hybrid?)” Microsoft: The Growth Center. 6월 20일. https://www.microsoft.com/en-us/microsoft-365/growth-center/resources/adopting-the-best-project-management-process-for-your-business.

Engel, Kristine. 2017. “송전선 설계를 위한 프로젝트 계획(Project Planning for Transmission Line Design).” 기술 프로젝트 관리 수업 PowerPoint 발표 자료, 위스콘신 대학교 매디슨 캠퍼스, 10월 12일.

Graban, Mark. 2014. “#린: 병원에서의 푸시, 풀, 플로 명확히 하기; 환자가 “당깁니다”.” Mark Graban의 린 블로그. 2월 24일. https://www.leanblog.org/2014/02/flow-push-and-pull-in-a-hospital/.

Green Wiki. 2015. “Sustainable Code Development.” Green Wiki. 6월 9일. http://green.wikia.com/wiki/Sustainable_code_development.

Hosey, Lance. 2005. “More Constructive Ways to Build a City.” The Washington Post, 1월 9일. http://www.washingtonpost.com/wp-dyn/articles/A57855-2005Jan7.html.

Kanari, N., J.L. Pineau, and S. Shallari. 2003. “End-of-Life Vehicle Recycling in the European Union.” Journal of the Minerals, Metals & Materials Society, 8월. 2015년 6월 9일 접속. http://www.tms.org/pubs/journals/jom/0308/kanari-0308.html.

Knee, Jonathan A. 2015. “In ‘Misbehaving,’ an Economics Professor Isn’t Afraid to Attack His Own.” New York Times, May 5. http://www.nytimes.com/2015/05/06/business/dealbook/book-review-misbehaving-by-richard-thaler.html?_r=1.

Larson, Erik W., and Clifford F. Gray. 2011. 프로젝트 관리: The Managerial Process, 제6판(Project Management: The Managerial Process, Sixth Edition). New York: McGraw-Hill Education.Laufer, Alexander. 2012. 프로젝트 관리에서 리더십 역할 마스터하기: 놀라운 성과를 내는 실천법(Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results). Upper Saddle River: FT Press.

Laufer, Alexander, Edward J. Hoffman, Jeffrey S. Russell, and Scott W. Cameron. 2015. “성공적인 프로젝트 관리자는 무엇을 하는가(What Successful Project Managers Do).” MIT Sloan Management Review, 봄: 43-51. http://sloanreview.mit.edu/article/what-successful-project-managers-do/.

Lean Enterprise Institute. 2014. 린 렉시콘(Lean Lexicon), 제5판. Edited by Chet Marchwinski. Cambridge, MA: Lean Enterprise Institute.

린 매뉴팩처링 툴스(Lean Manufacturing Tools). 연도 미상. “결함의 낭비: 원인, 증상, 사례 및 해결책.” 린 매뉴팩처링 툴스(Lean Manufacturing Tools). Accessed November 11, 2017. http://leanmanufacturingtools.org/129/waste-of-defects-causes-symptoms-examples-and-solutions/.

—. 연도 미상. “과잉생산의 낭비: 원인, 증상, 사례 및 해결책.” 린 매뉴팩처링 툴스(Lean Manufacturing Tools). Accessed November 11, 2017. http://leanmanufacturingtools.org/114/waste-of-overproduction-causes-symptoms-examples-and-solutions/.

Merrill, Robert, interview by Ann Shaffer. 2017. 위스콘신 대학교 매디슨 캠퍼스 수석 비즈니스 분석가 (10월 2일).

Merrow, Edward W. 2011. Industrial Megaprojects: Concepts, Strategies, and Practices for Success. Hoboken, New Jersey: John Wiley & Sons, Inc.

Mieritz, Lars. 2012. “Gartner 설문조사로 본 프로젝트 실패 원인(Gartner Survey Shows Why Projects Fail).” This Is What Good Looks Like. June 10. https://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail/.

ORC International: Expert Advisory Services. n.d. 신속 제품 개발 전문가(Rapid Product Development Experts). Accessed September 9, 2016. http://www.orcexperts.com/experts.asp?strSearchType=all&strQuery=rapid+product+development.

Pagenkopf, David. 2018. “Email on sustainability and software design.”

Thaler, Richard H. 2015. “Unless You Are Spock, Irrelevant things Matter in Economic Behavior.” New York Times, May 8. http://www.nytimes.com/2015/05/10/upshot/unless-you-are-spock-irrelevant-things-matter-in-economic-behavior.html?abt=0002&abg=0.

Vanderburg, Glenn. 2011. “Lone Star Ruby Conference 2010 Real Software Engineering by Glenn Vanderburg.” Published October 24, 2011. YouTube video, 51:56. https://www.youtube.com/watch?v=NP9AIUT9nos&feature=youtu.be

Womack, James P., and Daniel T. Jones. 2003. 린 사고: 기업에서 낭비를 몰아내고 부를 창출하라, 개정 증보판(Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated). New York: Free Press.

---