6
프로젝트 계획
전투를 준비하면서 나는 계획 자체는 쓸모없지만 계획을 세우는 일은 반드시 필요하다는 것을 늘 깨달았습니다.
–드와이트 D. 아이젠하워, 미국 대통령(1953-1961), 유럽 연합군 최고사령관(1943-1945)
학습 목표
이 단원을 읽고 나면 다음과 같은 일을 할 수 있습니다.
- 프로젝트 계획에 대한 살아 있는 질서의 접근 방식을 설명합니다
- 푸시 계획과 풀 계획을 설명하고 구별하기
- 프로젝트 계획에 대한 애자일 접근 방식 설명하기
- 지속 가능성과 지속적 개선 사이의 관계 설명하기
- 비상 계획과 관련된 문제 논의하기
이 단원의 핵심 개념
- 불확실성은 프로젝트 리더의 업무에 늘 따라다니는 특징입니다.
- 살아 있는 질서에서 계획은 학습하고 협업하며 적응하는 활동이며, 팀원들은 변화하는 상황에 대응하기 위해 언제든 계획을 변경할 준비가 되어 있습니다.
- 살아 있는 질서의 계획을 대표하는 예는 풀 계획으로, 풀 계획에서 계획 수립자는 먼저 원하는 최종 상태를 정한 다음 거꾸로 거슬러 올라가며 그 목표를 달성할 활동을 계획합니다.
6.1 계획에 대한 새로운 사고방식
메리엄-웹스터 사전은 계획을 "무언가를 달성하거나 하기 위해 계획을 세우는 행위 또는 과정"으로 정의합니다. 이는 계획 수립의 궁극적인 목표가 계획 그 자체임을 시사합니다. 또한 이 정의는 일단 계획이 수립되고 나면 그 계획을 따르기만 하면 원하는 결과를 얻을 수 있다고 전제합니다. 일상적인 대화에서는 그 정도로 충분합니다. 그러나 살아 있는 질서의 프로젝트 계획에 대해 생각하기 시작하면 계획의 본질을 더 폭넓게 이해하게 됩니다. 살아 있는 질서에서 계획은 실제로 전개되는 사건에 대응할 수 있도록 프로젝트 팀을 준비시키는 과정입니다. 계획 수립의 요점은 전적으로 다음 사항을 관리할 전략을 개발하는 데 있습니다.
- 범위 변경
- 일정
- 비용
- 품질
- 자원
- 의사소통
- 위험
- 조달
- 이해관계자 참여
계획 수립의 결과로 계획이 만들어지지만, 계획 그 자체가 목적은 아닙니다. 오히려 계획은 프로젝트의 일정 수립과 실행을 위한 전략적 틀입니다. 계획은 팀원들이 일을 진행하기 시작하는 데 필요한 정보를 담고 있을 때에만 유용합니다. 그리고 팀원들이 프로젝트에 관해 다음 사항을 알게 되면서 계획을 수정해 나갈 때에만 계속 유용합니다.
- 일정, 비용, 기능 요구 사항과 같은 핵심 제약 조건.
- 작업 흐름과 마일스톤 같은 프로젝트 시스템 문제에 관한 정보로, 프로젝트 전체를 폭넓게 조망하게 해 줍니다.
- 참여자와 리더십이 프로젝트와 그 최초 가정을 재평가할 수 있도록 하는 주기적인 점검 계획.
계획 수립은 불확실성을 받아들이는 것입니다
완고한 기하학적 질서의 계획 수립자들은 결정론적 접근 방식을 취하며, 모두가 계획에 동의하기만 하면 그 계획 자체가 다음에 일어날 일을 결정한다는 잘못된 생각에 사로잡혀 있습니다. 실제로 프로젝트 초기에 모든 세부 사항을 확정해 두고 뒤돌아보지 않고 나아갈 수 있다고 생각하고 싶은 유혹이 듭니다. 그러나 유능한 살아 있는 질서의 계획 수립자들은 특히 프로젝트 초기에는 이러한 세부 사항이 거의 언제나 잠정적이며 바뀔 수 있다는 것을 이해합니다. 따라서 유능한 살아 있는 질서의 계획 수립자들은 변화하는 상황 속에서 알게 된 것에 따라 계획을 바꿀 준비가 되어 있습니다. 또한 이들은 프로젝트가 전개되는 맥락에는 다양한 수준의 세부 사항과 변동성이 있으며, 프로젝트 생애주기 동안 잠재적으로 수천 가지의 결정이 내려진다는 것을 이해합니다. 그림 6-1은 프로젝트 내 개별 작업을 둘러싸고 점점 넓어지는 맥락의 원들을 보여 줍니다. 각 원은 프로젝트에 고유한 변동성과 불확실성을 더합니다.
Alexander Laufer와 Gregory Howell이 Project Management Journal(프로젝트 관리 저널)에 기고한 글에서 설명했듯이, 프로젝트 리더의 일은 불확실성에 기반을 두고 있습니다(1993). 이들은 불확실성이 다른 면에서는 예측 가능한 작업 과정 속의 예외적인 상태가 아니라고 주장합니다. 오히려 불확실성은 현대 작업의 영구적인 특징입니다. 더욱이 계획 수립과 실행 사이의 시간이 길어질수록 개별 활동을 둘러싼 불확실성은 더 커집니다. 당연히 프로젝트의 불확실성이 클수록 계획을 세우기는 더 어려워지고, 계획이 행동과 결과를 명확히 표현하는 데에도 덜 효과적이게 됩니다. 끝으로 이들은 아무리 많은 계획을 세워도 복잡한 프로젝트의 작업에 내재된 변동성을 없앨 수는 없다고 강조합니다.
복잡성에 대비한 계획 수립
Alexander Laufer와 Gregory Howell은 복잡한 프로젝트의 작업에 내재된 변동성은 계획 수립으로 없앨 수 없다는 점을 상기시킵니다(1993). 그렇다면 복잡한 프로젝트란 정확히 무엇입니까? 어려운 프로젝트는 모두 복잡한 프로젝트입니까? Tera Simon은 Team Gantt(팀 간트) 블로그 글에서 다음과 같이 설명합니다. "복잡한 프로젝트가 반드시 어려운 프로젝트인 것은 아닙니다. 프로젝트는 비용이나 성과 같은 이유로 어려울 수 있지만, 그렇다고 해서 그 프로젝트가 자동으로 복잡한 것은 아닙니다. 복잡성이란 모호성이나 불확실성을 포함하는 프로젝트를 가리킵니다. 그러한 프로젝트는 예측 불가능성에 둘러싸여 있습니다"(2016).
복잡한 프로젝트의 예로는 보스턴의 빅 딕(Big Dig) 같은 메가프로젝트부터, 아직 작동하지 않으며 변화가 잦은 의료 환경에서 사람들이 사용하게 될 의료 기술용 소프트웨어 개발처럼 보다 범위가 좁은 사업에 이르기까지 다양합니다. 진정으로 복잡한 프로젝트는 다음과 같은 특징 중 일부를 갖습니다.
-
- 프로젝트의 최종 목표에 대한 불확실성.
- 모호하게 정의되었거나 변화하는 제약 조건.
- 새롭거나 미흡한 기술.
- 이전에 검증된 적 없는 새로운 해결책의 필요성.
- 여러 분야에 걸친, 규모가 크고 계속 바뀌는 이해관계자 집단.
- 예측할 수 없는 기후나 지질학적 제약, 정치적 전환, 경제적 격변 등이 수반되는, 끊임없이 변화하는 상황.
복잡성이라는 개념을 좀 더 이론적으로 탐구하고 싶다면, 관리자가 복잡성을 이해하도록 돕기 위해 고안된 의사 결정 도구인 커네빈(Cynefin) 프레임워크에 대해 읽어 보십시오. 데이비드 스노든(David Snowden)과 메리 E. 분(Mary E. Boone)이 만든 커네빈 프레임워크는 리더가 "새로운 관점에서 사물을 보고, 복잡한 개념을 소화하며, 현실 세계의 문제와 기회에 대처할 수 있도록" 해 줍니다. 이 프레임워크는 여러분이 처한 상황의 유형(단순함, 난해함, 복잡함, 혼돈)을 파악한 다음 그 맥락에 적합한 선택을 하는 데 초점을 맞춥니다.
기술 프로젝트 관리자에게 이 프레임워크가 주는 가장 유용한 통찰은 난해한(complicated) 프로젝트와 복잡한(complex) 프로젝트를 구별하는 것입니다. Snowden과 Boone은 Harvard Business Review에 기고한 글에서 이 개념을 다음과 같이 논의합니다.
난해한 상황에서는 적어도 하나의 정답이 존재합니다. 그러나 복잡한 상황에서는 정답을 찾아낼 수 없습니다. 이는 이를테면 페라리와 브라질 열대 우림의 차이와 같습니다. 페라리는 난해한 기계이지만, 숙련된 정비사는 아무것도 바꾸지 않고 페라리를 분해했다가 다시 조립할 수 있습니다. 자동차는 정적이며, 전체는 부분의 합입니다. 반면 열대 우림은 끊임없이 변화합니다. 어떤 종은 멸종하고, 기상 패턴은 바뀌며, 농업 프로젝트는 수원의 물길을 돌려 놓습니다. 그리고 전체는 부분의 합을 훨씬 뛰어넘습니다. 이것이 바로 "모른다는 것조차 모르는 것"의 영역이며, 오늘날 비즈니스의 상당 부분이 옮겨 간 영역입니다. (2007)
더 읽을거리
- 커네빈 프레임워크에 관한 Snowden과 Boone의 글은 프로젝트 복잡성의 전체 범위를 설명하며, 더 많은 정보로 이어지는 링크도 포함하고 있습니다. https://hbr.org/2007/11/a-leaders-framework-for-decision-making.
- 복잡한 프로젝트에 관한 테라 사이먼(Tera Simon)의 글은 복잡한 프로젝트에 대처하는 데 필요한 역량을 설명합니다: https://www.teamgantt.com/blog/tackle-complex-projects.
- 캐슬린 B. 해스(Kathleen B. Hass)의 이 글은 다양한 복잡한 프로젝트를 설명하고, 새로운 프로젝트 관리 분야인 복잡 프로젝트 관리(complex project management)를 소개합니다: https://www.projecttimes.com/articles/managing-complex-projects-part-1.html
계획 수립은 학습입니다
살아 있는 질서에서는 프로젝트를 지식 개발 활동으로 생각하는 것이 도움이 됩니다. 그렇다면 프로젝트 계획 수립 이란 새로운 지식을 프로젝트 계획에 끊임없이 반영해 나가는 과정입니다. 매우 복잡하거나 낯선 프로젝트를 시작할 때는 원하는 결과를 달성하는 방법에 대해 거의 또는 전혀 모를 수도 있습니다. 하지만 끝날 무렵에는 훨씬 더 많은 것을 알게 됩니다. 더 많이 배울수록 원하는 프로젝트 결과를 달성하도록 계획을 세밀하게 조정하는 능력도 커집니다. 즉, 계획은 프로젝트가 진행됨에 따라 점점 구체화됩니다. 아직 완전히 이해하지 못한 요인에 대한 세부 사항을 계획에 넣고 싶은 유혹을 이겨 내는 것이 중요합니다. 그런 세부 사항은 거의 틀림없이 잘못된 것으로 드러나기 때문입니다. 프로젝트에 영향을 줄 수 있는 여러 요인에 대한 이해 수준을 넘어서는 정밀도로 계획을 세우지 않도록 주의하십시오.
이처럼 적응적인 계획 수립 방식을 받아들이면, 프로젝트 계획 수립을 근본적으로 다른 방식으로 다룰 수 있습니다. "어떻게 하면 프로젝트를 원래 계획으로 되돌릴 수 있을까?"라고 끊임없이 묻는 대신, "이 새로운 지식을 어떻게 활용해야 계획을 다듬고 프로젝트 성공 가능성을 높일 수 있을까?"라고 물을 수 있습니다. 무언가를 배우거나, 차질을 겪거나, 성공을 거두었을 때, 그 경험을 진행 중인 계획 과정에 반영할 또 하나의 데이터 포인트로 다룰 수 있습니다. 그것은 이전에는 없던 정보이며, 프로젝트 결과를 향해 나아가는 여정에서 전체 프로젝트 계획을 개선하는 데 활용할 수 있습니다.
무지의 상태에서 발견의 상태로 넘어가는 것이 불가피하다는 사실을 받아들이고 나면, 프로젝트 계획 수립에서 확실성이 과연 가능한지 의문을 품기 시작할 것입니다. 유용한 경험칙은 이렇습니다. 프로젝트의 앞날이 어떻게 될지 확신한다면, 아마도 여러분이 틀렸거나 실제로는 프로젝트 계획이 필요 없는 경우일 것입니다. 간단한 작업 목록으로 충분할 수도 있습니다. 이는 작업이 여러 장소에서, 변화하고 종종 예측할 수 없는 상황 속에서 이루어지는 분야에서 특히 그렇습니다. 도라 코헨카-잘(Dora Cohenca-Zall), 알렉산더 라우퍼(Alexander Laufer) 등이 건설 프로젝트 계획 수립에 관한 연구에서 입증했듯이, "높은 수준의 불확실성은 예외가 아니라 일반적인 현상"입니다(1994). 1과에서 살펴보았듯이, 현대의 프로젝트는 피터 베일(Peter Vaill)이 "끝없는 급류(permanent whitewater)"라고 부르는 상태 속에서 전개됩니다(Laufer 2012). 프로젝트 수명 주기 전반에 걸쳐 발생할 수 있는 모든 문제를 예견하는 것은 그야말로 불가능합니다.
프로젝트 계획 수립의 궁극적인 목표는 전개되는 상황에 적응할 수 있을 만큼 충분한 유연성을 갖춘, 잘 숙고된 전략입니다. 계획 수립자 자신은 심리학자들이 인지적 재구성이라고 부르는 것, 즉 사건과 사실을 새로운 시각으로 바라보기 위해 다시 생각해 보는 일에 끊임없이 임해야 합니다. 그래야만 프로젝트 수명 주기 내내 변화하는 상황에 적응할 수 있습니다.
계획 수립은 적응이자 협업입니다
프로젝트 계획의 목표는 누가 무엇을, 어떻게, 어떤 목적으로 만드는지를 설명하는 것입니다. 다시 말해, 프로젝트 계획은 협업을 위한 도구입니다. 계획 수립 과정 자체가 하나의 협업 활동이며, 이는 흔히 구성원 간에 신뢰를 쌓고 다양한 구성원으로 이루어진 팀이 제공하는 여러 관점을 활용하는 팀 리더의 역량을 처음으로 시험하는 자리가 됩니다. 계획 수립에 성공하려면 활용할 수 있는 모든 팀워크 기술과 기법이 필요하며, 5강에서 논의했듯이 여기에는 신뢰할 수 있는 약속, 감성 지능, 현실적인 관점, 그리고 뛰어난 의사소통 능력이 포함됩니다. 팀원들이 서로를 더 많이 신뢰할수록, 변화하는 상황에 적응하는 데 필요한 위험을 더욱 기꺼이 감수하게 됩니다.
Alexander Laufer, Terry Little, Jeffrey Russell, Bruce Maas는 프로젝트 리더 되기(Becoming a Project Leader)에서 적응과 협업을 촉진하여 변동성이 크고 복잡한 프로젝트를 헤쳐 나간 프로젝트 관리자들의 이야기를 들려줍니다(2018). 이 성공적인 관리자들은 네 가지 핵심 전략을 결합했습니다.
- 진화하는 계획 수립: 프로젝트가 전개됨에 따라 프로젝트 팀이 프로젝트에 대한 지식을 넓혀 갈 것이라고 전제하는, 학습 기반의 프로젝트 계획 수립 접근 방식입니다.
- 대응적 민첩성: 프로젝트가 전개되는 동안 문제를 해결하기 위해 신속하게 행동하고, 이를 명확하고 최신의 의사소통과 결합하는 것입니다.
- 선제적 회복탄력성: 잠재적인 문제를 예방하기 위해 "현状을 선제적이고 선별적으로" 문제 삼는 것입니다.
- 협력적 팀워크: 유연하고 대응력 있으며 상호작용하는 팀워크를 장려하는 것입니다.
Alexander Laufer, Terry Little, Jeffrey Russell, Bruce Maas는 프로젝트 리더 되기(Becoming a Project Leader)에서 확고한 약속을 하기 어려운 변동성 큰 상황에서 계획에 연동 계획(rolling wave) 접근 방식을 적용하는 것의 가치를 설명합니다. 성공적인 프로젝트 관리자들은 "프로젝트가 전개되고 정보의 신뢰도가 높아짐에 따라 물결처럼 단계적으로" 계획을 수립합니다. 이 접근 방식은 "상세한 단기 계획"을 90일 단위의 중기 계획, 그리고 프로젝트 전체 기간을 아우르는 보다 개괄적인 마스터 계획과 결합하는 것을 포함합니다.
이러한 계획 수립 방식은 결정을 임의로 "나중으로 미루어야" 한다는 뜻이 아닙니다. 오히려 앞으로 더 적절한 시점에 실행할 수 있는 계획 요소를 의도적으로 분리해 내는 행위입니다. 이 접근 방식을 적용하면 두 가지 극단적인 상황을 피할 수 있습니다. 첫째는 지나치게 상세한 계획을 너무 일찍 준비하는 것으로, 일부 결정이 신뢰할 수 있는 데이터가 아니라 지적인 추측에서 나온 정보에 기반하기 때문에 계획이 금세 쓸모없어질 수 있습니다. 또 다른 극단적인 상황은 모든 정보가 완전하고 안정될 때까지 계획 수립을 미루는 것입니다. 두 경우 모두 프로젝트의 효과성이 떨어지게 됩니다. 프로젝트의 적절한 단계에서 더 상세한 내용을 제공하는 계획 수립 방식을 채택해야만 시의적절하고 확고한 결정을 내릴 수 있습니다. (18-19)
6.2 기하학적 질서 접근 방식: 푸시
전통적인 기하학적 질서 방식의 계획 수립은 충분한 조사와 사전 숙고가 있으면 계획 수립자가 대부분의 사태를 예견할 수 있다는 생각에 기반을 두고 있습니다. 다시 말해, 기하학적 질서에 따라 계획을 수립하는 사람들은 프로젝트가 시작되기 전에 프로젝트에 관한 모든 것, 또는 거의 모든 것을 알 수 있다고 가정합니다. 계획 수립자들은 프로젝트가 전개되는 동안 조정할 필요가 거의 없을 것이라고 가정하기 때문에, 기하학적 질서 계획 수립은 순차적이고 예측 가능한 활동들이 선형적으로 진행된다고 전제합니다. 각 참여자는 위계적이고 순차적인 질서 속에서 특정한 자리를 차지합니다.
기하학적 질서 계획 수립은 새 하수관 매설처럼 단순하고 예측 가능하며 반복하기 쉬운 활동에 잘 맞습니다. 이 방식은 각 활동이 일정대로 진행된다고 전제하면서 개별 활동을 최적화하는 데 초점을 맞추는 경향이 있습니다. 이러한 사고방식의 문제는 계획 수립자들이 서로 의존하는 활동들에 수반되는 불확실성을 무시하게 만든다는 점입니다. 예를 들어, 해외 시장을 겨냥한 제품을 설계하고 있는데 무역 전쟁이 발발하여 그 제품에 높은 관세가 부과되고, 그 결과 제품 가격이 훨씬 비싸진다고 가정해 보십시오. 그런 경우에는 제품, 제품의 잠재 시장, 그리고 어쩌면 제조 장소까지 다시 생각해야 할 것입니다.
푸시 계획(push plan)이라는 용어는 기하학적 질서 원칙을 가정하여 수립된 프로젝트 계획을 가리키는 데 사용됩니다. 계획이 완성되고 나면 작업은 그에 따라 전개되어 미리 정해진 프로젝트 결과로 이어질 것이라고 가정합니다. (그림 6-2 참조.) 푸시 계획이 일단 실행에 옮겨지면, 이해관계자들은 계획의 각 부분이 계속 진행되도록 하는 데 집중하는 경향이 있습니다. 푸시라는 용어는 제조업에서 "생산이 예상 생산 계획에 기반하며, 정보가 자재가 흐르는 방향과 같은 방향으로 경영진에서 시장으로 흐르는" 시스템을 설명하기 위해 처음 사용되었습니다(BusinessDictionary n.d.).
푸시 시스템은 일반적으로 고객 수요 예측을 중심으로 구축되는데, 이 예측은 맞을 수도 있고 틀릴 수도 있습니다. 그러나 일단 푸시 계획이 실행되면, 생산 과정에서는 최종 제품에 대한 실제 수요보다 계획의 각 부분을 계속 진척시켜야 할 필요성이 더 중요하게 여겨집니다. 푸시 계획은 프로젝트 유형과 수행할 활동이 잘 알려져 있고 이전 프로젝트와 매우 유사한 경우에 적합할 수 있습니다. 또한 일반 대중을 위한 범용 상품을 생산할 때에도 적합합니다. 건설업과 제조업에서 푸시 계획의 궁극적인 목표는 가능한 한 최저 비용으로 제품을 생산하는 것입니다. 푸시 계획 프로젝트에서 하도급업체는 일정과 예산에 맞춰 작업을 완료하는 데 집중하며, 그래야 자신의 작업이 끝났다고 선언하고 다른 프로젝트로 넘어갈 수 있기 때문입니다. 푸시 계획은 인력 가용성 예측을 중심으로 구축되는데(그림 6-3 참조), 이러한 예측은 실제로 하기 어렵고 틀리는 경우가 많습니다. 한편, 관리자는 일반적으로 미리 정해진 생산 일정을 지키는 능력으로 평가받습니다. 이런 식으로 푸시 프로젝트는 개인의 이해관계에 의해 추진되며, 협업과 조정을 통해 작업 흐름을 관리하고 낭비를 방지하는 프로젝트에 대한 고려는 거의 이루어지지 않습니다.
푸시 계획은 때때로 재고 생산(make-to-stock)이라고도 불립니다. 이는 푸시 방식의 제조 시스템이 수요 예측에 기반하여 대량의 품목을 가능한 한 가장 빠른 속도로 처리한 다음, 이를 "다음 하류 공정이나 창고로" 옮긴다는 개념입니다(Plex 2017). 이는 푸시를 단순화하여 이해하는 방식이지만, 기본 개념을 파악하기 시작하는 데에는 좋은 방법입니다. 이를 위해 푸시 시스템의 몇 가지 간단한 예를 소개합니다.
- 인쇄되어 창고로 배송된 교과서가 그곳에서 서점의 주문을 기다리는데, 서점은 그 교과서가 필요할 수도 있고 필요하지 않을 수도 있습니다. 총 인쇄 부수는 부분적으로는 학생 수요에 대한 판매 예측에, 부분적으로는 인쇄소가 인쇄하려는 최소 부수에 따라 결정됩니다.
- 제조되어 세인트루이스의 철물점으로 배송되는 인도용 제설 소금입니다. 기온이 한 번도 영하로 내려가지 않는 유난히 따뜻한 겨울에도 매년 같은 양이 배송됩니다.
극도로 잘못된 푸시 계획을 보여 주는 유머러스하면서도 유익한 예로, 왈가닥 루시(I Love Lucy)의 유명한 초콜릿 포장 장면을 보십시오. 이 장면에서 가엾은 루시와 에셀은 점점 빨라지는 컨베이어 벨트를 따라잡으려 애씁니다:
이 버전의 텍스트에서는 YouTube 요소가 제외되었습니다. 다음 주소에서 온라인으로 볼 수 있습니다: https://wisc.pb.unizin.org/technicalpm/?p=944
푸시 계획의 더 복잡한 예는 제조, 제품 개발, 의료, 건설 등 모든 산업에서 찾아볼 수 있습니다. 특정 시스템의 다양한 프로세스를 살펴보고 특정 프로세스가 작업을 시작하게 만드는 계기가 무엇인지 파악하면 푸시 시스템을 식별할 수 있습니다. 푸시 시스템에서는 상류 프로세스가 다음 하류 프로세스로 작업을 밀어 넣을 책임을 집니다. 예를 들어 병원에서 응급실은 새로 도착한 환자를 하류인 수술 병동으로 밀어 보내 시술을 기다리게 할 수 있습니다(그림 6-4 참조). 수술 병동에 빈 병상이 없으면 환자는 병상이 날 때까지 응급실에서 기다려야 합니다. "작업의 이전이 상류(즉, 이전) 프로세스의 책임"인 이러한 푸시 환경에서는 응급실 인력이 상황을 관리하여 최종적으로 환자가 하류인 수술 병동에 실제로 자리를 얻도록 해야 합니다(Institute for Healthcare Improvement n.d.).
푸시 시스템에는 어느 한 시점에 시스템 내에서 진행될 수 있는 작업량에 대한 명시적인 제한이 전혀 없습니다(Hopp and Spearman 2004, 142). 일단 작업이 시작되면 오류, 자원 가용성 및 기타 문제로 인한 지연과 관계없이 계속 진행되어야 합니다. 따라서 문제가 실제로 발생하면, 시스템은 린(Lean) 및 기타 살아 있는 질서 방법론에서 볼 수 있는 흐름 평가 및 개선을 위한 내장 메커니즘이 없기 때문에 거의 기어가듯 느려지거나 완전히 멈춰 버립니다.
소프트웨어 개발에서 푸시 계획의 고전적인 예는 그림 6-5에 나타낸 폭포수 모델입니다. 가장 순수한 형태의 폭포수 모델은 소프트웨어 개발을 개별적이고 순차적인 단계의 집합으로 봅니다. 이 모델은 프로젝트 결과를 높은 수준으로 예측할 수 있다고 전제하며, 프로젝트가 진행되는 동안 조정할 기회는 거의 또는 전혀 없습니다. 실제로 프로젝트가 테스트 단계에 이르면, 비용을 비롯한 여러 고려 사항 때문에 되돌아가 원래 계획을 바꾸는 것이 거의 불가능해집니다.
푸시 계획의 수많은 변형이 근본적으로 매력적인 까닭은 세상이 정해진 규칙에 따라 돌아간다고 전제하기 때문입니다. 어쨌든 아이작 뉴턴이 가르쳐 주었듯이, 우리는 물리 법칙이 예측 가능한 결과를 낳는 세상에 살고 있습니다. 미식축구공을 떨어뜨리면 그 공이 땅에 떨어진다는 것을 우리는 압니다. 공을 던지면 그 공이 공중을 날아간다는 것도 압니다. 다시 말해, 우리는 신중하게 계획하면 예측 가능한 결과를 얻을 수 있다고 생각하도록 길들여져 있습니다. 그러나 그러한 정적인 기하학적 질서의 사고방식은 현대 프로젝트 계획의 현실을 제대로 반영하지 못합니다. 우리는 살아 있는 질서를 고려해야 합니다.
폭포수 모델: 약간의 역사
폭포수 모델은 윈스턴 W. 로이스(Winston W. Royce)가 1970년에 발표한 논문 「대규모 소프트웨어 시스템 개발 관리(Managing the Development of Large Software Systems)」에서 처음 소개했습니다. 로이스는 개발자가 프로젝트 초기에 상세한 계획을 세운 다음 세밀한 명세에 맞추어 코드를 작성함으로써 예측 가능한 결과를 내는 이상적인 개발 프로세스를 설명했습니다. 그러나 로이스는 이것을 소프트웨어를 개발하는 현실적인 방법으로 권장한 것이 아니었습니다. 실제로 그의 폭포수 도표 바로 다음 문장은 "나는 이 개념을 신뢰하지만, 위에서 설명한 구현 방식은 위험하며 실패를 부른다"라고 되어 있습니다(Royce). 그로서는 매우 실망스럽게도, 지나치게 단순화된 폭포수 방법에 대한 그의 설명은 1970년대와 1980년대 소프트웨어 개발계에 들불처럼 번져 나갔습니다. 폭포수 방법의 역사를 흥미롭게 풀어낸 이야기를 보려면 글렌 밴더버그(Glen Vanderburg)의 다음 영상을 9:00부터 시청하십시오.
"Real Software Engineering – Glenn Vanderberg, Lone Star Ruby Conference 2010."
이 버전의 텍스트에서는 YouTube 요소가 제외되었습니다. 다음 주소에서 온라인으로 볼 수 있습니다: https://wisc.pb.unizin.org/technicalpm/?p=944
6.3 살아 있는 질서의 접근 방식: 풀 계획
풀 계획은 프로젝트 계획에 살아 있는 질서의 접근 방식을 실제로 적용한 것입니다. 풀 계획은 협업적이고 유연하며 반복적이고, 이해관계자가 새로운 정보에 적응해야 하는 매우 복잡한 프로젝트에 특히 적합합니다. 풀 계획은 정기적으로 조율하며 현재 상황을 반영하도록 계획을 갱신하는 작업자 집단을 전제로 합니다. 풀 계획은 실제로 완료할 수 있는 만큼만 생산하고 그 이상은 생산하지 않는 데 초점을 둡니다. 풀 계획의 궁극적인 목표는 가능한 최고의 가치를 창출하는 것입니다.
풀의 바탕이 되는 사고방식은 1948년 "도요타 생산 방식의 아버지"로 알려진 오노 다이이치(Taiichi Ohno)에게서 비롯되었으며, 도요타 생산 방식은 다시 린(Lean)과 애자일(Agile)로 이어졌습니다. 식량 부족이 자주 문제가 되던 제2차 세계 대전 이후의 일본에 살던 오노는, 고객이 원하는 것을 원하는 때에 마치 마법처럼 제공하는 듯한 미국 슈퍼마켓에서 영감을 얻었습니다.
우리는 슈퍼마켓에서 생산 라인의 앞 공정을 일종의 상점으로 보는 아이디어를 얻었습니다. 뒤 공정(고객)은 필요한 부품(상품)을 필요한 때에 필요한 양만큼 얻기 위해 앞 공정(슈퍼마켓)으로 갑니다. 앞 공정은 방금 가져간 양만큼 즉시 생산합니다(진열대를 다시 채웁니다). (Ohno 1988, 26)
풀 시스템은 때때로 주문 생산(make-to-order)이라고도 불립니다. 이는 고객이 주문을 하면, 그 시점에 생산 시설 전체가 가동되어 그 하나의 주문을 처리하는 데 필요한 품목을 만들어 낸다는 의미입니다. 이것은 풀을 매우 단순화한 형태이지만, 유용한 출발점이 됩니다. 다음 두 가지 공급망 사례는 이러한 기초적인 형태의 풀을 보여 줍니다.
- 한 학생이 온라인으로 교과서를 주문하면, 그 교과서 한 부가 인쇄되어 학생에게 직접 배송됩니다.
- 페인트 가게의 한 고객이 마지막 남은 프라이머 세 통을 카트에 담으면, 이를 계기로 점원이 프라이머 진열함을 다시 채웁니다.
실제로 풀에서 "고객"이라는 개념은 단순히 최종 사용자보다 더 넓은 의미를 지닙니다. 풀 시스템에서는 하류 공정이 그 앞의 상류 공정의 고객입니다. 건설 현장에서 이것이 의미하는 바는 다음과 같습니다.
모든 작업은 고객의 당김에 따라 수행됩니다. 따라서 전기 기술자는 자신의 고객인 석고보드 시공자가 석고보드 세우기를 시작할 수 있도록 벽체 내부 배선 작업을 마무리합니다. 석고보드 시공자는 자신의 고객인 도장공이 작업을 시작할 수 있도록 석고보드를 붙입니다. 프로젝트 마일스톤에서부터 거꾸로 작업해 나감으로써 … 모든 작업이 계획 안으로 당겨지도록 합니다. 그 결과 작업은 단지 할 수 있을 때마다가 아니라 적절한 시점에 이루어집니다. (Lemke 2016)
풀 계획은 린(Lean)의 핵심 개념으로, 린은 푸시 계획의 특징인 불가피한 중단과 재개(즉, 낭비) 없이 작업이 매끄럽게 흐르는 것을 중시합니다. 그림 6-6에서 보듯이, 풀 계획은 불필요한 단계를 제거하여 전통적인 푸시 계획에 따라 설계된 유사한 프로젝트를 완료하는 데 필요한 시간을 최대 3분의 1까지 절약합니다.
린 사고에서 계획은 유동적인 실시간 프로세스입니다. 효과적인 린 프로젝트 계획자가 되려면 살아 있는 질서가 계속 진화한다는 점을 이해해야 합니다. 계획은 더 이상 공식적으로 미리 정의된 정적인 계획을 모든 팀원에게 전달하고 강화하는 일이 아닙니다. 계획이란 각 팀원에게 프로젝트에 대해 사고하는 방식과 새로운 지식을 계획에 반영하는 프로세스를 제공하고, 프로젝트가 전개됨에 따라 계획을 재설정할 수 있는 정기적인 선택지를 마련해 주는 일입니다.
6.4 푸시와 풀의 구분
풀 계획에서는 먼저 프로젝트의 바람직한 최종 상태, 즉 창출하고자 하는 가치를 파악하는 것부터 시작합니다. 그런 다음 거꾸로 거슬러 올라가며 그곳에 도달하는 가장 효율적인(낭비가 가장 적은) 방법을 결정합니다. 이는 카약을 타는 사람들이 급류 구간의 맨 아래까지 걸어 내려간 뒤 위를 올려다보며 급류를 통과할 계획을 세우는 것과 비슷합니다. 그 후에 그들은 급류의 시작 지점으로 돌아가 앞에 놓인 난관을 더 잘 파악한 상태에서 급류를 헤쳐 나가려 시도할 수 있습니다.
풀 시스템의 본질을 파악하는 가장 좋은 방법은 푸시와 비교해 보는 것입니다. 간단한 예로, 유럽 휴가를 계획하고 있다고 가정해 봅시다. 푸시 계획 방식을 취한다면, 방문할 나라들의 추천 명소를 모두 목록으로 만드는 것부터 시작할 것입니다. 그 결과는 사용 가능한 모든 시간을 여러 목적지에 배분하는 일정이 될 것입니다. 이러한 휴가 계획은 본질적으로 해야 할 일이나 봐야 할 것의 체크리스트입니다. 반면에 풀 방식은 집으로 돌아가는 길에 어떤 기분을 느끼고 싶은지, 즉 여행이 창출하기를 바라는 가치에 전적으로 초점을 맞춥니다. 가능한 명소와 활동의 목록은 똑같이 검토할 수 있지만, 그중 어떤 것을 계획에 포함할지에 대한 결정은 여행이 끝났을 때 어떤 기분을 느끼고 싶은지에 따라 달라집니다.
그림 6-7은 두 가지 유형의 휴가, 즉 편안히 쉬었다는 기분을 남기는 휴가와 새로운 경험으로 활력을 얻었다는 기분을 남기는 휴가에 대한 풀 계획의 시작 단계를 보여 줍니다. 모든 풀 계획이 그렇듯이, 비결은 끝에서 시작하는 것입니다. 집으로 돌아가는 길에 어떤 기분을 느끼고 싶습니까? 그런 다음 그림 6-8에서 보듯이, 결국 그런 기분을 느끼도록 보장해 주는 활동을 계획에 추가할 수 있습니다. 보시다시피 두 그림 모두에 포스트잇이 사용되었습니다. 선택할 수 있는 일정 관리 및 계획 프로그램은 많지만, 매우 단순한 아날로그 수단인 포스트잇은 이리저리 옮기기 쉬워 계획 수립자가 새로운 아이디어를 시도해 보도록 장려하기 때문에 풀 일정 수립에서 널리 사용됩니다.
풀 계획의 실제
풀 계획에 대한 보다 폭넓은 소개를 원한다면, 이 책의 저자들이 제작한 1시간 분량의 이 동영상을 참고하십시오. 이 동영상은 휴가 계획을 예로 들어 풀 계획의 핵심 개념을 설명합니다.
이 버전의 텍스트에서는 YouTube 요소가 제외되었습니다. 다음 주소에서 온라인으로 볼 수 있습니다: https://wisc.pb.unizin.org/technicalpm/?p=944
다양한 환경에서 작동하는 푸시와 풀을 식별하는 법을 익히면, 조직이 목표를 달성하기 위해 둘 중 하나를 사용하거나 두 방식을 결합하는 모습이 보이기 시작할 것입니다. 사실 "현실 세계에는 순수한 푸시 시스템이나 순수한 풀 시스템이 존재하지 않습니다"(Hopp and Spearman 2004, 143). 또한 푸시와 풀의 개념이 맥락에 따라 서로 다른 관심사를 강조하는 데 사용된다는 점도 알게 될 것입니다.
예를 들어, 이 용어들이 공급망 관리의 세계에서 어떻게 사용되는지 생각해 보십시오. 공급망 관리는 "원자재 추출부터 소비자 구매에 이르기까지, 올바른 제품을 올바른 수량으로 올바른 시점에 올바른 소비자의 손에 전달하기 위해 이루어져야 하는 모든 활동"을 포괄합니다(Mays Business School n.d.). 공급망 관리에서 푸시/풀 전문가들은 흔히 시스템의 푸시 부분과 풀 부분 사이의 경계에 대해 이야기합니다(Sehgal 2009). 다음 예에서처럼, 푸시와 풀 사이의 경계는 대개 제품이 소비자 수요에 대한 일반적인 예측을 바탕으로 푸시 환경에서 제조되어, 특정 고객의 구체적인 요청이 제품을 시장으로 끌어낼 때까지 창고에 보관된 이후에 나타납니다:
식품 제조업체는 버섯 수프를 만들어 자사 상표뿐 아니라 여러 슈퍼마켓 체인의 상표 등 몇 가지 방식으로 브랜드를 붙일 수 있습니다. 제조업체는 매달 필요한 수프의 양을 잘 파악하고 있습니다. 그러나 수요를 충족하기 위해 수프를 어떻게 포장해야 할지는 그만큼 확신하지 못합니다. 그 결과, 제조업체는 버섯 수프를 대량 생산하여 주문이 들어올 때까지 라벨을 붙이지 않은 캔 상태로 재고를 보관하는 방식을 택할 가능성이 높습니다. 그런 다음 고객이 주문하면 캔에 신속하게 라벨을 붙여 출하할 수 있습니다. (McGinley 2016)
그러나 푸시와 풀 개념의 이러한 좀 더 특수한 응용 때문에 풀의 근본적인 의미를 놓쳐서는 안 됩니다. 여러분의 전문 분야가 무엇이든, 새 프로젝트에 풀 사고를 어느 정도 적용한다면 결코 잘못될 일이 없습니다. 프로젝트의 바람직한 최종 상태는 무엇입니까? 프로젝트가 어떤 가치를 창출하기를 원합니까? 무엇보다도, 그것을 달성하기 위해 프로젝트 이해관계자와 어떻게 협업하겠습니까?
풀 방식의 대중 연설
위스콘신 대학교 매디슨 캠퍼스에서 공학 경영 석사 과정을 밟고 있는 Matthew David Potter는 수업 발표를 준비할 때 자신이 넣고 싶은 내용보다는 동료 학생들에게 유용할 내용에 집중하려고 노력했다고 말했습니다. 다시 말해, 모든 뛰어난 커뮤니케이터처럼 그는 청중의 요구에 초점을 맞추었습니다. 나중에 그는 청중에 집중하는 것이 사실 풀 사고의 한 형태, 즉 바람직한 최종 상태에서 출발한 다음 그것을 달성할 방법을 찾아내는 방식이라는 것을 깨달았습니다.
그는 자신의 경험을 다음과 같이 요약합니다.
- 끝(고객)에서 시작하여 세 가지 핵심 요점(가치)을 정하고, 슬라이드를 만들면서 그 가치를 거꾸로 끌어당기면(가치 흐름과 흐름), 최종 결과물이 훨씬 더 탄탄해집니다. 그런 접근 방식을 취하자 저에게는 흥미로울 수 있지만 주요 요점을 전달하는 데 꼭 필요하지는 않은 정보(낭비)를 덜어내게 되었습니다.
- 반면에 기하학적 푸시 방식은 공유하고 싶은 모든 정보를 파악하는 것에서 시작하여, 중요한 요점마다 슬라이드를 만들고, 그런 다음 이 모든 것을 하나로 엮고 어떻게든 편집하여 발표를 정해진 시간 안에 맞추느라 허둥대는 과정으로 이어집니다(개인 서신, 2018년 6월 15일).
6.5 풀과 애자일
애자일 소프트웨어 개발은 계획에 대한 반복적 접근 방식을 강조합니다. 소프트웨어 개발에 대한 전통적인 폭포수 방식은 소프트웨어 요구 사항이 정해진 후에는 프로젝트에 변경이 거의 없을 것이라고 전제하는 반면, 애자일은 프로젝트 참여자가 변화하는 상황에 적응할 수 있도록 특별히 설계되었으며, 그러한 상황 중 가장 중요한 것은 흔히 소프트웨어 요구 사항에 대한 고객의 생각이 계속 바뀌는 것입니다. 애자일 프로젝트 계획자는 처음에 프로젝트 전체를 계획하는 대신, 1~2주 단위의 개발 스프린트를 통해 빠르게 진화하는 제품 반복본을 만들어 내는 데 집중합니다.
프로젝트의 시작이 명확히 정의되어 있고 명확히 정의된 끝에 이를 때까지 작업이 차례로 전개된다고 전제하는 전통적인 프로젝트 관리와 달리, 애자일 프로젝트 관리는 반복적이고 순환적인 흐름을 가집니다. 이 흐름을 추진하는 원동력은 소프트웨어가 자신들의 요구를 얼마나 잘 충족하는지에 대해 제품 책임자가 제공하는 지속적인 피드백입니다. 소프트웨어가 형태를 갖추기 시작하면, 제품 책임자는 다음과 같은 결정을 계속해서 요청받습니다.
또한 어떤 기능을 가장 중요하게 여기는지, 그리고 프로젝트 예산과 일정을 맞추기 위해 어떤 기능을 생략할 수 있는지에 관한 피드백입니다. 이는 애자일 개발에서는 프로젝트가 끝날 때까지 계획이 끝나지 않는다는 것을 의미합니다. 예측 가능성은 자연스럽게 나타날 시간을 주면 나타나지만, 너무 일찍 억지로 끌어내려 하면 손에 잡히지 않습니다. 애자일이 주는 혜택 중 하나는 스스로 보정된다는 점입니다. 스프린트를 몇 차례 진행하고 나면 특정 팀, 후원자, 기술, 요구 사항에 맞게 보정된 실제 진척 속도가 드러나기 시작합니다. (Merrill 2017)
다양한 유형의 제품에서 소프트웨어의 중요성이 점점 커짐에 따라, 빠른 피드백과 수정의 주기를 갖춘 애자일은 John Deere 같은 대형 제조업체를 포함하여 제품 개발 분야에서 더욱 보편화될 가능성이 높습니다. 애자일 개발의 주기는 작동하는 소프트웨어를 더 빨리 만들어 내므로, 제품 개발 수명 주기의 더 이른 시점에 마케팅 부서와 고객으로부터 피드백을 받기가 쉬워집니다. 이 새로운 형태의 제품 개발은 애자일 엔지니어링이라고 불리며, 팀이 전통적인 제품 개발 방식보다 더 빠르게 제품에 대해 배우고 개선하도록 장려합니다. 고급 3D 프린터 제조업체인 FormLabs의 블로그 게시물에서 Joris Peels는 다음과 같이 씁니다.
프로토타입을 통해 실패로부터 배우면 기업은 더 나은 제품을 빠르게 만들 수 있습니다. 가정을 검증하고 데이터를 수집함으로써, 이러한 제품은 더 정확하고 증거에 기반한 방식으로 만들어집니다.
전통적인 방식에서는 팀이 공들여 세계 지도를 만든 다음, 이 상상 속의 세계를 지나는 가능한 경로를 계획하는 데 몇 달을 보냅니다. 그런 뒤에야 비로소 제품을 손에 쥐고 자신들이 실제로 어디에 서 있는지 알게 됩니다. 애자일 엔지니어링에서는 제품 개발 첫 주에 제품이 모습을 드러냅니다. 팀은 길을 나서서 나침반을 자주 확인합니다. (2016)
6.6 지속가능성: 지속적 개선을 위한 계획
지속적 개선은 "업무를 간소화하고 낭비를 줄일 기회를 찾아내는 방법"입니다(LeanKit n.d.). 린에서 카이젠(kaizen, 일본어로 개선이라는 뜻)으로 알려진 지속적 개선은 린과 애자일의 핵심 개념이지만, 모든 유형의 조직에서 원동력이 됩니다. 지속적 개선을 조직의 철학에 온전히 통합하려면, 계획 단계부터 시작하여 프로젝트에 이를 반영해야 합니다. 실제로 계획 과정 자체가 미래를 내다보고 일을 더 잘하는 방법을 고민하는 일을 포함하므로, 그 자체로 지속적 개선 활동입니다.
지속적 개선은 체계적인 지속가능성 변화를 추구하는 조직과 지속가능성에 관심을 둔 개별 프로젝트에 중요한 개념입니다. 이는 장기간에 걸쳐 진행되는 프로젝트에서 특히 그러한데, 프로젝트 진행 도중에 새로운 지속가능성 기술이 등장할 수 있기 때문입니다. Becoming Part of the Solution: The Engineer’s Guide to Sustainable Development 의 저자 Bill Wallace에 따르면, 기업의 지속가능성 노력을 확대하는 데 전념하는 지속적 개선 프로그램에는 다음이 포함되어야 합니다.
기준선 평가. 기업은 현재 자사가 환경과 사회에 미치는 영향을 파악해야 합니다. 이를 위해서는 먼저 기업 활동의 범위를 정의하고, 그 활동이 미치는 영향을 기존 성과 표준, 규범 또는 벤치마킹 대상 기업과 비교하여 평가해야 합니다….
개선 목표 설정. 기준선 평가 결과를 바탕으로 기업은 포괄적인 개선 목표를 수립해야 합니다. 목표는 확립된 지표에 비추어 측정할 수 있어야 합니다. 일정…또한 수립해야 합니다….
실행. 목표와 일정이 정해지면, 기업은 실행 프로그램을 마련하고 목표 달성에 충분한 자금을 배정해야 합니다. 정기적인 지속가능성 성과 보고서를 작성하여 최고 경영진에게 전달해야 합니다…. 보고서에는 현재의 관행을 바꿀 수 있는 기술 발전에 대한 평가도 포함되어야 합니다.
검토 및 수정. 기업은 목표와 계획 대비 진행 상황을 점검하고 프로그램 자금이 어떻게 사용되었는지 확인하기 위해 정기적인 검토 일정을 잡아야 합니다…. 프로그램 성과, 고객 기대, 새로운 벤치마크, 신기술, 전사적 성과 또는 기타 변수에 근거하여 목표를 재검토하고 그에 맞게 수정해야 합니다. (2005, 95)
6.7 비상 계획에 관한 한마디
프로젝트 계획을 수립하는 것 외에도 비상 계획을 수립해야 합니다. 비상 계획이란 프로젝트 성공을 가로막을 수 있는 주요 장애물에 대처하기 위한 계획입니다. 비상 계획은 다양한 위험이 현실화될 경우에 대비하여 프로젝트의 대체 경로를 정의합니다. 비상 계획에는 일반적으로 예비비가 포함되는데, 이는 예상치 못한 비용을 충당하기 위해 따로 마련해 두는 자원입니다. 비상 계획과 예비비가 필요한 이유는, 아무리 노련한 프로젝트 계획자라도 때로는 모든 일이 순조롭게 진행되고 필요한 때에 모든 자원을 확보할 수 있으리라 가정하며 지나친 낙관에 빠지기 때문입니다. 또한 프로젝트를 아무리 철저하게 계획하더라도 적어도 몇 가지 사소한 문제는 놓치게 마련입니다.
예비비 사용이 필요할 수 있는 문제의 예는 다음과 같습니다.
- 불충분한 초기 추정
- 계획에 포함되지 않은 소소한 항목
- 초기 추정의 오류
- 불가피한 지연으로 인한 작은 편차
예비비는 큰 편차나 범위 변경을 관리하기 위한 것이 아니라는 점에 유의하십시오.
간단하면서도 효과적인 비상 계획의 한 형태는 최종 예산에 명시된 금액과 별도로 전체 자원(시간, 비용, 인력)의 일정 비율로 구성된 예비비를 따로 마련해 두는 것입니다. 일반적으로 10퍼센트가 통상적인 수준이지만, 이는 프로젝트의 규모와 유형은 물론 산업 유형에 따라서도 달라질 수 있습니다. 예를 들어, 애리조나 주립대학교가 캠퍼스 건설 프로젝트를 위해 만든 이 예비비 지침은 다양한 예비비 비율 범위를 보여 줍니다: “프로젝트 예비비 지침.” 마찬가지로, 미국 에너지부는 비상 계획에 대한 고정 비율 접근 방식을 여기에서 설명합니다: “예비비.”
비상 계획의 주요 어려움 중 하나는 예비비가 정확히 무엇을 충당하고 무엇을 충당하지 않는지, 그리고 특정 상황에서 어떻게 적용되는지에 대해 사람들의 합의를 이끌어 내는 것입니다. 이 주제에 관해서는 상당히 많은 연구가 이루어졌지만, 아직 명확한 합의는 없습니다. 따라서 대규모 프로젝트를 시작하기 전에 구체적으로는 소속 조직의, 넓게는 해당 산업의 비상 계획에 관한 세부 사항을 조사해 두는 것이 현명합니다.
비상 계획은 8과에서 다루는 위험 관리와 밀접한 관련이 있습니다. 복잡도가 제한된 소규모 프로젝트를 진행할 때는 고정 비율 비상 계획으로 대부분의 위험을 충당할 수 있다고 가정해도 무방할 것입니다. 그러나 매우 복잡하고 기술적으로 까다로운 프로젝트의 경우에는 (고정 비율을 사용하는) 일반적인 예산 계획상의 예비비와, 불확실성에 대비한 보다 정교한 위험 모델링을 구별하는 것이 중요합니다.
실용적인 팁
- 적절한 수준의 세부 사항을 사용하십시오: 프로젝트 계획은 꼭 필요한 만큼의 세부 사항을 담아 적절한 수준으로 작성해야 합니다. 세부 사항이 거의 없는 매우 개략적인 계획은 모든 이해관계자에게 의미 있게 다가가지 못합니다. 반면에 불필요한 세부 사항과 끝없는 작업 목록으로 가득 찬 극도로 복잡한 프로젝트 계획은 갱신하기가 너무 어려워서, 사람들이 아예 갱신을 소홀히 하는 경우가 많습니다. 그렇게 되면 그러한 계획은 쓸모없는 것보다도 못한 것이 됩니다. 경험적으로 볼 때, 프로젝트 계획에는 15~50개의 활동이 필요합니다. 그러면 계획이 실행에 옮길 수 있을 만큼 충분히 상세하면서도 계속 갱신할 수 있을 만큼 관리하기 쉬운 상태를 유지하는 데 도움이 됩니다. 그런 다음 하위 계획을 사용하여 작업을 더 세부적으로 나눌 수 있습니다.
- 변화하는 현실을 반영하도록 계획을 조정할 준비를 하십시오: 프로젝트를 계획할 때, 고정된 목표를 맞히려 한다고 절대 가정하지 마십시오. 대다수의 프로젝트에서 목표는 실제로 움직입니다. 유연성을 갖추고 필요에 따라 계획을 조정해야 합니다.
- 적절한 정밀도 수준으로 계획하십시오: 프로젝트에 영향을 미칠 수 있는 여러 요인에 대한 이해 수준을 넘어서는 정밀도로 계획하지 않도록 주의하십시오. 그렇게 하면 낭비가 두 번 발생합니다. 처음에는 계획 과정에서, 그리고 나중에는 실제 상황을 반영하도록 계획을 수정해야 한다는 사실을 알게 되는 실행 단계에서 발생합니다. 예를 들어 계획의 결과로 $380,275,465.47과 같은 추정치가 나온다면, 그 계획이 비현실적인 수준의 정밀도를 담고 있다고 확신해도 됩니다. 그러한 수준의 정밀도는 현실 세계에는 존재하지 않는 수준의 정확도를 암시합니다. 그러한 프로젝트의 가치가 3억 5천만 달러에서 4억 달러 사이 어딘가라고 말하는 편이 더 유용합니다.
- 일정 관리 기술을 여러 계획 도구 중 하나로 사용하십시오: 프로젝트 관리 소프트웨어처럼 모든 이해관계자가 이해하고 접근 방법을 알고 있는 기술 도구를 사용하십시오. 그러나 일정을 만드는 것이 프로젝트를 계획하는 것과 같다고 생각하는 실수를 저지르지 마십시오. 일정은 프로젝트 계획의 한 측면에 불과합니다.
- 성공에 시선을 고정하십시오: 계획 과정 전반에 걸쳐 프로젝트 성공의 정의에 분명하게 초점을 맞추십시오.
- 모두 모여 계획하십시오: 팀이 여러 지역에 흩어져 있다면, 적어도 계획 단계의 일부 기간 동안에는 모두가 한곳에 모이도록 노력하십시오. 이는 표현이 서툰 이메일이나 일부 이해관계자가 다른 이들보다 더 주도권을 쥘 수 있는 전화 회의로 인해 생긴 오해를 해소하는 데 큰 도움이 될 수 있습니다.
- 프로젝트 계획을 총체적으로 생각하십시오: 좋은 프로젝트 계획은 프로젝트의 모든 요소를 다룹니다. 이 3.5분짜리 동영상은 프로젝트를 계획할 때 고려해야 할 사항을 간략하게 소개합니다. "프로젝트 계획에는 무엇이 들어가는가?”
~요약
- 살아 있는 질서에서 계획은 그 자체로 목적이 아니라, 프로젝트의 일정 수립과 실행을 위한 전략적 틀입니다. 프로젝트를 지식 개발 활동으로 생각하면 도움이 됩니다. 그렇다면 프로젝트 계획이란 새로운 지식을 프로젝트 계획에 지속적으로 반영하는 과정입니다. 프로젝트 계획은 협업을 위한 도구이며, 계획 과정 자체가 하나의 협업 활동입니다. 이 활동은 흔히 구성원 간에 신뢰를 구축하고 다양한 팀이 제공하는 여러 관점을 활용하는 팀 리더의 역량을 처음으로 시험하는 자리가 됩니다.
- 기하학적 질서의 계획은 순차적이고 예측 가능한 활동이 선형적으로 진행된다고 전제합니다. 푸시 계획(push plan)이라는 용어는 기하학적 질서의 원칙을 전제로 수립된 프로젝트 계획을 가리키는 데 사용됩니다.
- 풀 계획은 프로젝트 계획에 살아 있는 질서의 접근 방식을 실제로 적용한 것입니다. 풀 계획은 협력적이고 유연하며 반복적이고, 이해관계자가 새로운 정보에 적응해야 하는 매우 복잡한 프로젝트에 특히 적합합니다. 풀 계획은 정기적으로 조율하며 현재 상황을 반영하여 계획을 갱신하는 협력적인 작업자 집단을 전제로 합니다. 풀 계획은 실제로 완료할 수 있는 만큼만 생산하고 그 이상은 생산하지 않는 데 초점을 맞춥니다.
- 애자일은 소프트웨어 개발에 풀 계획 접근 방식을 취합니다. 애자일은 반복적이며, 소프트웨어 요구 사항에 대한 고객의 생각이 변화함에 따라 끊임없이 적응하는 것을 전제로 합니다.
- 린과 애자일의 핵심 개념인 지속적 개선은 체계적인 지속 가능성 변화를 추구하는 조직과 지속 가능성에 관심을 두는 개별 프로젝트에 중요한 개념입니다.
- 프로젝트 계획을 수립하는 것과 더불어, 프로젝트 계획에 명시되지 않은 결과에 대응하는 비상 계획도 수립해야 합니다.
용어집
- 애자일 엔지니어링—애자일 소프트웨어 개발에서 처음 구현된 빠른 피드백과 수정의 반복 주기를 활용하는 새로운 형태의 제품 개발입니다. 애자일 엔지니어링은 팀이 전통적인 제품 개발에서보다 더 빠르게 제품에 대해 배우고 개선하도록 장려합니다.
- 인지적 재구성—사건과 사실을 새로운 방식으로 보기 위해 다시 생각해 보는 과정입니다.
- 비상 계획—진행에 장애물이 생길 경우 실행할 수 있는, 프로젝트 성공에 이르는 대안 경로에 대한 계획입니다.
- 예비비—예상하지 못한 비용을 충당하기 위해 따로 마련해 둔 자원입니다.
- 계획—프로젝트의 일정 수립과 실행을 위한 전략적 틀입니다. 전통적인 기하학적 질서의 프로젝트 계획에서 계획은 사건이 예측 가능한 방식으로 전개될 것이라고 전제하므로 계획을 갱신할 필요가 거의 없습니다. 살아 있는 질서의 프로젝트 계획에서 계획은 언제나 잠정적이며 변경될 수 있습니다.
- 계획 편향—실제로 현실적인 수준보다 더 빠르고 더 적은 비용으로 프로젝트를 끝낼 수 있다고 생각하게 만드는 인지 편향입니다.
- 프로젝트 계획—전통적인 기하학적 질서의 프로젝트 계획에서는 프로젝트의 나머지 부분을 이끌어 갈 계획을 수립하는 과정입니다. 살아 있는 질서의 프로젝트 계획에서 "프로젝트 계획"은 새로운 지식을 초기 프로젝트 계획에 지속적으로 반영하는 과정도 가리킵니다.
- 풀 계획—예측할 수 없고 끊임없이 변화하는 살아 있는 질서의 본질을 고려하는 프로젝트 계획입니다. 풀 계획을 수립하는 사람은 프로젝트의 원하는 최종 상태에서 시작하여 거꾸로 거슬러 올라가며 원하는 결과를 달성하는 가장 효율적인(낭비가 가장 적은) 방법을 결정합니다. 풀 계획이 효과를 거두려면 정기적으로 조율하며 현재 상황을 반영하여 계획을 갱신하는 협력적인 작업자 집단이 필요합니다.
- 풀 일정표—일반적으로 필요에 따라 떼어 내거나 위치를 옮길 수 있는 색상별 접착식 메모지로 구성된 일정표입니다. 이는 여러 가지 소프트웨어 프로그램으로도 구현할 수 있습니다. 핵심은 최종 목표에서 시작한 다음 거꾸로 거슬러 올라가며 그 목표를 달성하는 데 필요한 작업을 결정하는 것입니다.
- 푸시 계획—사건이 예측 가능한 기하학적 질서에 따라 전개될 것이라고 전제하는 프로젝트 계획입니다. 푸시 계획은 고객 수요에 대한 경영진의 예측에 기반하며, 계획의 각 부분을 계속 진행시켜야 할 필요성을 크게 강조합니다. 관리자와 하도급업체는 프로젝트에서 각자 맡은 부분에 집중하며, 협력과 조율을 통해 작업 흐름을 관리하고 낭비를 방지하는 데에는 거의 관심을 두지 않습니다.
- 공급망 관리—"원자재 추출부터 소비자 구매에 이르기까지, 올바른 제품을 올바른 수량으로 올바른 시점에 올바른 소비자의 손에 전달하기 위해 이루어져야 하는 모든 활동"(Mays Business School n.d.)입니다.
- 폭포수 모델—개발 과정을 개별적이고 순차적인 일련의 단계로 나누는, 소프트웨어에 사용되는 푸시 계획 모델입니다. 폭포수 모델은 예측 가능한 프로젝트 결과를 전제로 하므로 프로젝트가 전개되는 동안 조정할 기회가 거의 또는 전혀 없습니다.
추가 자원
- 이 책의 저자들이 제작한 1시간 분량의 이 동영상은 휴가 계획 세우기를 예로 들어 풀 계획의 핵심 개념을 설명합니다: https://go.wisc.edu/livingpm.
- Lean Construction Institute의 용어집으로, “푸시”와 “풀”의 정의를 담고 있습니다: “Push” and “Pull” Definitions.
- 이 책에서 Peter Vaill은 "끝없는 급류"라는 용어를 소개합니다. Managing as a Performing Art: New Ideas for a World of Chaotic Change(1989).
- 이 동영상에서 워크숍 참가자들은 플라스틱 블록으로 집 두 채를 짓는데, 첫 번째 집은 전통적인 푸시 계획에 따라 짓고 두 번째 집은 풀 계획의 요소를 활용하여 짓습니다: “Pull Planning Workshop: San Diego Mesa College.” 풀 계획으로 지은 집이 더 빨리 완성되었고, 팀원 간의 협력도 더 활발했으며 전반적인 만족도도 더 높았다는 사실은 그리 놀랍지 않을 것입니다.
참고 문헌
BusinessDictionary. 연도 미상. “Push System.” BusinessDictionary. 2018년 7월 1일 접속. http://www.businessdictionary.com/definition/push-system.html.
Cohenca-Zall, Dora, Alexander Laufer, Aviad Shapira, and Gregory A. Howell. 1994. "Process of Planning during Construction(시공 중 계획 과정)." Journal of Construction Engineering and Management, September: 561-578. http://tx.technion.ac.il/~avishap/During-Construction-Planning.pdf.
Hopp, Wallace J., and Mark L. Spearman. 2004. “To Pull or Not to Pull: What is the Question?” Manufacturing & Service Operations Management 133-148.
Institute for Healthcare Improvement. 연도 미상. “Use Pull Systems to Improve Flow.” ihi.org. 2018년 7월 1일 접속. http://www.ihi.org/resources/Pages/Changes/UsePullSystems.aspx.
Laufer, Alexander. 2012. Mastering the Leadership Role in Project Management: Practices that Deliver Remarkable Results(프로젝트 관리에서 리더십 역할 숙달하기: 놀라운 성과를 내는 실천 방법). Upper Saddle River: FT Press.
Laufer, Alexander, Terry Little, Jeffrey Russell, and Bruce Maas. 2018. Becoming a Project Leader: Blending Planning, Agility, Resilience, and Collaboration to Deliver Successful Projects(프로젝트 리더 되기: 계획, 민첩성, 회복탄력성, 협업을 결합하여 성공적인 프로젝트 수행하기). New York: Palgrave Macmillan.
LeanKit. n.d. "What is Continuous Improvement?(지속적 개선이란 무엇인가?)" LeanKit. 2018년 7월 1일 접속. https://leankit.com/learn/kanban/continuous-improvement/.
Lemke, Klaus. 2016. "3 Simple Rues for Effective Pull Planning(효과적인 풀 계획을 위한 3가지 간단한 규칙)." LeanProject. 12월 15일. http://www.leanproject.com/news/3-simple-rules-for-effective-pull-planning/.
Mays Business School. n.d. "What is Supply Chain Management?(공급망 관리란 무엇인가?)" Mays Business School, Texas A&M University. 2018년 7월 1일 접속. http://mays.tamu.edu/department-of-information-and-operations-management/what-is-supply-chain-management/.
McGinley, Bill. 2016. “How to Determine When to Use Push or Pull Production Scheduling.” Carpedia. 10월 24일. http://carpedia.com/blog/determine-use-push-pull-production-scheduling/.
Merrill, Robert, Ann Shaffer와의 인터뷰. 2017. 위스콘신 대학교 매디슨 캠퍼스 수석 비즈니스 분석가(10월 2일).
Ohno, Taiichi. 1988. 도요타 생산 방식: 대량 생산을 넘어서. Cambridge, MA: Productivity press.
Peels, Joris. 2016. “Why Agile Engineering is the Future of Product Design.” FormLabs. 3월 7일. 2017년 10월 5일 접속. https://formlabs.com/blog/agile-engineering-product-development/.
Plex. 2017. “Push vs. Pull Manufacturing: Is a Kanban Pull System Right for Your Company?” Industry Week, 7월 28일. http://www.industryweek.com/cloud-computing/push-vs-pull-manufacturing-kanban-pull-system-right-your-company.
Royce, W.W. 1987. “Managing the development of large software systems: Concepts and Techniques.” ICSE ’87 Proceedings of the 9th international conference on Software Engineering. Monterey: IEEE Computer Society Press. 328-338.
Sehgal, Vivek. 2009. “푸시인가 풀인가?” 공급망에 관한 단상. 10월 7일. http://www.supplychainmusings.com/2009/10/push-or-pull.html.
Simon, Tera. 2016. 복잡한 프로젝트를 전문가처럼 해결하는 데 필요한 5가지 핵심 역량. 12월 5일. 2019년 9월 10일 접속. https://www.teamgantt.com/blog/tackle-complex-projects.
Snowden, David J., and Mary E. Boone. 2007. “A Leader’s Framework for Decision Making.” Harvard Business Review. https://hbr.org/2007/11/a-leaders-framework-for-decision-making.
Thomack, David. 2018. “린과 프로젝트 딜리버리 입문.” CEE 498: 건설 관리 동영상 강의. 위스콘신 대학교 매디슨 캠퍼스, 공과대학, 4월 20일.
Thomsen, Chuck, Joel Darrington, Dennis Dunne, Will Lichtig. n.d. “통합 프로젝트 딜리버리 관리.” LeanConstruction.org. 2018년 9월 26일 접속. https://www.leanconstruction.org/wp-content/uploads/2016/02/CMAA_Managing_Integrated_Project_Delivery_1.pdf.
Wallace, Bill. 2005. Becoming Part of the Solution: The Engineers Guide to Sustainable Development. Washington, D.C.: American Council of Engineering Companies.