기존 프로젝트를 원활하게 인수하는 방법에 대한 완전한 가이드

소개

프로젝트 관리자(PM)로서 우리는 프로젝트를 처음부터 시작할 수 있는 여유가 거의 없습니다. 대부분의 경우 우리가 프로젝트를 관리할 때 우리보다 먼저 다른 사람이 이미 프로젝트를 시작했습니다. 그러한 프로젝트를 성공적으로 인수하기 위해 프로젝트 관리자는 모든 것이 고려되었는지 확인하기 위해 특정 원칙을 적용해야 합니다.

이 가이드에서는 문제를 5가지 수준으로 분류하여 주의를 기울여야 한다고 생각하는 가장 중요한 단계를 간략하게 설명합니다.

이 인수 프로세스는 프로젝트를 실행하는 데 사용된 방법론(Waterfall, Agile 등)과 완전히 독립적이며 수집할 정보의 범위와 취해야 할 조치를 나타냅니다.

프로젝트 관리자는 프로젝트를 시작하는 즉시 이러한 각 범주의 모든 관련 정보를 수집하는 것을 목표로 해야 합니다. 이 중 일부는 새로운 동료와 팀원을 만나면서 자연스럽게 이루어집니다. 그러나 회의를 설정하고, 정보를 검색하고, 내부 소스에서 문서화하는 데 더 적극적이어야 하는 경우도 있습니다. 어떤 상황에 처해 있든 이 가이드가 프로젝트를 원활하게 전환하는 데 도움이 되는 참고 자료가 되기를 바랍니다.

회사 수준

회사 미션 및 비전

너무 많은 PM이 회사의 미션과 비전을 제대로 파악하지 못한 채 일상 업무에 뛰어듭니다. 이러한 용어는 진부하게 들리거나 직원의 일상적인 현실과 동떨어져 보일 수 있지만, 특히 기존 이력이 있는 프로젝트를 수행하는 PM의 경우 과소평가될 수 없습니다.

일부 경우(일반적으로 소규모 회사에서)는 명시적으로 모두 명시되지 않을 수 있습니다. 다른 경우에는 사명과 비전이 하나의 성명으로 결합되어 있습니다. 일종의 존재 이유 입니다. 그러나 프로젝트를 인수할 때 회사 사명과 비전을 모두 이해하는 데 최소한 시간을 투자해야 하는 두 가지 이유가 있습니다.

• 높은 수준의 개요를 위한 정신적 토대를 제공합니다. 의미를 즉시 이해하지 못한다면 직속 상사에게 해석을 요청하고 이해한 방법을 설명하도록 하십시오. 비즈니스, 제품 및 프로젝트의 목표를 훨씬 쉽게 내면화할 수 있습니다.
• 그것은 당신과 당신의 팀에 목적을 제공합니다. 이 중 어느 것이 더 흥미진진합니까?

회사의 사명과 비전을 내면화하면 특히 일이 어려울 때 일상 업무에서 더 많은 목적을 찾을 수 있습니다. 또한 필요할 때마다 팀에 영감을 주고 공유 목적을 만들 수 있는 장비를 더 잘 갖추게 됩니다.

기업 문화

회사 문화는 특히 새로운 회사에서 프로젝트를 인수할 때 살펴봐야 할 중요한 측면입니다. 회사는 사람들이 의사 소통하고 함께 일하는 방식에 영향을 미치는 매우 다양한 유형의 문화를 가질 수 있습니다. 사회적 구조와 회사의 다른 부분 간의 관계에 대한 이 메타 정보는 예산을 협상하거나 이해 관계자에게 영향을 미치거나 단순히 다른 부서와 의사 소통을 시도할 때 매우 유용할 수 있습니다.

예를 들어, 은행과 같은 전통적인 금융 기관은 복장 규정에서 부서가 특정 책임을 맡고 누구에게 도움을 요청할 것인지에 이르기까지 모든 것에 대해 많은 불문율 규칙이 있는 매우 엄격한 회사 문화를 가지고 있는 경향이 있습니다. 팀을 인수할 때 이러한 점을 고려해야 합니다. 그래야 팀에 익숙한 문화적 규범 내에서 팀에 더 잘 적응하고 협력할 수 있습니다.

반면에 일부 스타트업은 사람들이 직접 만나는 경우가 거의 없는 외진 문화를 가지고 있습니다. 대신 대부분의 사회적 상호 작용은 Slack 및 JIRA와 같은 도구를 통해 발생합니다. 이러한 "원격 우선" 문화는 보다 전통적인 프로젝트 관리 환경에서 온 프로젝트 관리자에게 생소할 수 있습니다. 이 시나리오에서는 가능한 한 원활한 커뮤니케이션을 위해 좋은 마이크와 웹캠이 있는지 확인하십시오. 또한 사람들과 정기적으로 연락하여 관계를 발전시키십시오.

프로젝트를 인수할 때 새 회사에 존재하는 문화적 규범을 인식하고 그에 따라 행동과 관리 스타일을 조정하십시오.

지역적 의사결정 vs. 글로벌적 의사결정

어느 회사에서나 프로젝트 관리자가 따라야 하는 규칙 및 절차와 달리 스스로 결정할 수 있는 결정이 있습니다. 절차는 회사가 성장함에 따라 변경되는 경향이 있습니다. 혼란을 줄이고 회사 운영 방식을 표준화하기 위해 전 세계적으로 더 많은 결정이 내려집니다.

이것은 나중에 프로젝트 수명 주기에서 프로젝트에서 결정을 내리는 방법에 영향을 미치기 때문에 이해하는 것이 중요합니다. 예를 들어, 프로젝트 관리자의 책임은 기업에 비해 스타트업에서 매우 다를 수 있습니다. 물론, 항상 분배가 있을 것입니다. 예를 들어 PM이 행동 방침을 공식화할 수 있지만 고위 경영진의 승인이 필요한 경우입니다.

다음은 몇 가지 상황과 결정이 지역적으로 또는 전 세계적으로 이루어지면 어떻게 달라지는지입니다.

회사가 어떤 경우에 속하는지 알면 프로젝트의 의사 결정을 준비하는 데 도움이 됩니다.

비즈니스 및 제품 수준

비즈니스 모델

프로젝트 인수의 첫 날에는 전체 회사, 비즈니스 및 제품에 대한 높은 수준의 정신적 그림을 만들고 프로젝트가 이러한 요소에 어떻게 부합하는지 파악하는 데 시간을 할애해야 합니다. 어떤 식으로든 귀사는 미션과 비전을 수행할 수 있도록 돈을 벌고 있습니다.

프로젝트 인수의 초기 단계에서 모든 수익 흐름과 성장 지표를 암기하는 데 많은 시간을 할애할 필요가 없습니다. 그러나 돈이 회사 안팎으로 어떻게 이동하는지, 주요 수익 동인과 비용 센터가 무엇인지 파악하려고 노력하십시오. 또한, 회사 전체의 중장기 목표(신시장 진출 등)가 있는지 물어보세요. 이에 대한 지식이 있으면 현재 진행 중인 선택과 향후 프로젝트에 미치는 영향을 더 잘 이해하는 데 도움이 됩니다.

제품

귀하의 회사에는 수익을 창출하는 하나 이상의 제품이 있으며 귀하의 프로젝트는 그 중 하나의 일부가 될 것입니다. 제품을 이해하면 프로젝트를 올바른 컨텍스트에 더 잘 배치하는 데 도움이 됩니다. 시작하기에 좋은 곳은 제품을 직접 테스트하는 것입니다. 다음은 제품을 처음에 더 잘 이해하기 위해 해결해야 하는 질문 목록입니다.

• 제품이 내부입니까 외부입니까?
• 제품의 주요 사용자는 누구입니까? 같은 사람들이 제품을 구매합니까?
• 이 제품은 어떤 단계(MVP, 성장, 하락)에 있습니까?
• 제품은 어떻게 마케팅되나요?
• 주요 경쟁자는 누구입니까?

이러한 질문에 대한 답을 알면 프로젝트의 이유와 전체 제품 비즈니스 가치 사슬에서 프로젝트가 적합한 위치를 더 잘 이해하는 데 도움이 됩니다.

이해관계자

PM의 가장 중요한 업무 중 하나는 이해관계자 관리입니다. 시간과 예산 내에서 제공하더라도 팀은 오래된 이해 관계자의 요구 사항을 처리하고 있을 수 있습니다. 또는 이해 관계자에게 충분한 정보가 없으면 프로젝트에 투자하지 않을 수 있습니다. 이해 관계자 관리는 지속적이고 일상적인 작업이지만 프로젝트를 인수할 때 초기에 고려해야 할 몇 가지 중요한 사항이 있습니다.

PMBOK(Project Manager Book of Knowledge)에는 필요한 도구와 방법론을 사용하여 이해 관계자를 식별하는 전체 장이 있습니다. 이 작업은 매우 중요하고 시간이 다소 소요되지만 첫날에 살펴봐야 하는 가장 중요한 이해 관계자 그룹은 다음과 같습니다.

• 프로젝트 팀. 여기에는 개발자, 디자이너, QA 전문가 등과 같은 팀 구성원이 포함됩니다. 귀하의 팀은 제품 및 비즈니스 의사 결정의 이력과 이전에 작업에 어떤 영향을 미쳤는지에 대한 심층적인 통찰력을 제공할 수 있습니다. 이는 향후 반복될 수 있는 문제를 식별하는 데 도움이 될 수 있습니다.
• 프로젝트 후원자. 프로젝트를 구상하고 자금을 확보한 한 사람(직속 관리자 또는 스타트업 공동 설립자) 또는 기업 내 사람들 그룹이 될 수 있습니다. 프로젝트 후원자는 프로젝트의 챔피언이며 기존 프로젝트와 그 역사에 대한 개요를 얻기 위해 연락하는 첫 번째 이해 관계자 중 하나여야 합니다.
• 포트폴리오 관리자 또는 프로그램 관리자. 이러한 역할이 모든 회사에 있는 것은 아닙니다. 그러나 이들은 일반적으로 여러 기능과 비즈니스 관련 프로젝트를 한 번에 관리합니다. 그들은 프로젝트를 더 넓은 맥락으로 이해하고 참여해야 하는 관련 프로젝트 및 기타 PM이 있는지 파악하는 데 도움이 됩니다.
• 고객 또는 사용자. B2C, B2B 또는 내부 제품에서 작업하든 간에 프로젝트에는 여전히 일종의 사용자 그룹이 있습니다. 팀에 제품 관리자가 포함된 경우 이 이해 관계자 그룹과 그들의 기대에 대한 개요를 제공할 수 있어야 합니다. 그렇지 않으면 현재 피드백이 무엇인지 그리고 향후 프로젝트에 대해 무엇을 기대하는지 이해하기 위해 연락하십시오.

이러한 이해 관계자를 식별한 후에는 RACI 매트릭스를 만들어 전체 프로젝트 구조에서 해당 이해 관계자가 어디에 속하는지, 그리고 이들이 프로젝트에 영향을 미칠지 여부와 영향을 더 잘 이해할 수 있습니다.

프로젝트 레벨

왜 인수합니까?

예산, 일정, 팀 등을 살펴보기 전에 가장 먼저 물어야 할 질문은 "인계받는 이유는 무엇입니까?"입니다. 세 가지 시나리오가 가장 그럴듯합니다.

• 이전에는 프로젝트 관리자가 없었고 모든 것이 균열을 통해 미끄러지기 시작했습니다. 이것은 일반적으로 작고 짧은 프로젝트가 점점 더 커질 때 발생합니다. 특별한 문제가 없을 수도 있지만 더 많은 구조와 진행 상황에 대한 가시성이 필요합니다. 프로젝트와 관련된 이 문서의 제안 사항을 구현하세요.
• 프로젝트 관리자가 제거되거나 해고되었습니다. 이 경우 주요 이해 관계자에게 가장 큰 문제가 어디에 있었는지 물어보고 초기에 해당 영역에 집중했는지 확인해야 합니다. 이해 관계자의 신뢰와 신뢰를 얻기 위해 몇 가지 빠른 성공을 찾으십시오.
• 이전 프로젝트 관리자가 떠났습니다. PM이 어딘가에서 더 나은 제안을 받았지만 이해 관계자가 작업에 만족했기 때문에 떠났습니까? 그렇다면 현상을 유지하면서 개선의 기회를 찾으십시오. PM이 몇몇 이해관계자들과 어울리지 않아 떠났다면 가능하면 전 PM에게 연락해서 의논하세요. 문제의 이해 관계자와 관계를 구축하는 것이 귀하에게 매우 중요합니다.

범위, 일정 및 예산

기존 프로젝트의 범위를 파악하는 것은 새 프로젝트를 시작할 때와 다릅니다. 후자의 경우 이해 관계자로부터 요구 사항을 수집하고 보유한 예산에 따라 범위를 정의합니다. 인수할 때 누군가가 이 작업을 수행했을 것이며 이제 정의된 범위가 현실적이고 달성 가능한지 이해하는 것이 귀하의 임무입니다.

첫 번째 자연스러운 단계는 기존 프로젝트 자산을 살펴보는 것입니다. Gantt 차트, WBS(작업 분석 구조) 또는 Agile 백로그 및 릴리스 계획이 될 수 있습니다. 때로는 직접 예산 대신 내부 회사 팀이 할당한 시간으로 인해 제약을 받게 됩니다. 이 경우 다른 마감일이 있는지, 다른 약속으로 인해 프로젝트가 지연될 수 있는지 알아내십시오.

무엇을 찾든 주요 이해 관계자와 프로젝트 범위 및 일정을 재정렬해야 합니다. "당신이 인수하는 이유는 무엇입니까?"라는 질문을 기억하십시오. 관리되지 않는 이해 관계자의 기대가 이전 PM이 제거 된 이유 일 수 있습니다. 따라서 이 경우에는 이러한 일이 다시 발생하지 않도록 선택되었습니다. 범위, 일정 또는 예산이 비현실적임이 드러날 수 있습니다. 가능한 빨리 이 결론에 도달하고 프로젝트 후원자와 논의하십시오. 프로젝트 인수의 초기 단계는 이전에 저지른 실수를 수정하기에 좋은 시간이지만 이러한 문제를 해결하기 위해 더 오래 기다릴수록 이해 관계자는 프로젝트를 완료할 수 있는 능력에 대해 더 많이 의심할 수 있습니다.

프로젝트 챔피언 찾기

프로젝트와 그 이해 관계자를 탐색하는 동안 프로젝트의 성공에 투자한 사람들에 대해 더 많이 찾는 것이 중요합니다. 이러한 이해 관계자 중 일부는 프로젝트 챔피언이라고도 합니다.

직접적으로 책임지지 않더라도 프로젝트의 원인에 동의하는 사람들입니다. 그들은 당신의 프로젝트가 성공할 수 있도록 최선을 다할 것입니다. 예를 들어, 새로운 시간 추적 애플리케이션을 구축하는 경우 프로젝트 챔피언은 프로젝트가 완료되고 회사에서 배포되는 것을 보는 데 관심이 있는 사람들입니다.

프로젝트를 성공적으로 수행하는 데 필요한 사항에 대한 귀중한 통찰력을 제공할 수 있으므로 조기에 식별하는 것이 중요합니다. 때로는 제품의 초기 버전을 테스트하고 피드백을 제공하거나 동료에게 제품의 중요성을 옹호함으로써 간접적으로 도움을 줄 수도 있습니다.

프로젝트 팀 동료 및 이니셔티브에 대한 개념을 처음 개발한 사람들과 이야기하여 이러한 챔피언을 찾아보십시오. 발견되면 프로젝트 수명 주기에 대한 정보와 업데이트를 유지하십시오.

팀 레벨

팀 관계 및 구조

프로젝트를 인수하는 경우 팀이 이미 자리를 잡고 있을 것입니다. 먼저 그것을 상수로 취급하고 팀이 어떻게 구성되어 있고 어떻게 운영되며 팀 내에서 누가 주요 영향을 미치는지 파악해야 합니다. 이 프로젝트를 위해 팀이 모였습니까? 아니면 과거에 함께 작업한 적이 있습니까? 팀이 형성, 스토밍, 규범화 또는 수행 중 어느 단계에 있습니까? 팀이 같은 위치에 있습니까, 아니면 멀리 떨어져 있습니까? 모두가 직원입니까 아니면 팀에서 함께 일하는 계약자 또는 프리랜서입니까?

이 모든 질문은 프로젝트를 성공적으로 관리하는 능력에 영향을 미치며 그 과정에서 접근 방식을 조정해야 합니다. 예를 들어, 당신의 팀이 아직 폭풍우가 몰아치는 단계에 있다면, 당신은 팀 구성원들의 관계를 관리하여 그들이 최대 성과 수준에 도달하기 전에 그들을 정상화하도록 밀어붙여야 할 것입니다. 팀은 자체 내에서 별도의 단계에 있을 수도 있습니다. 별도의 사무실이 거의 없는 경우 팀의 다른 부분이 매우 다른 역학을 가질 수 있으며 팀 전체뿐만 아니라 다른 위치에서도 팀 역학을 정규화하기 위해 추가 노력을 기울여야 할 수 있습니다.

또한 원격으로 작업하는 팀 구성원이 있는 경우 대화와 일상적인 의사 결정에 포함되어 있는지 확인해야 합니다. 그렇지 않으면, 그들은 단지 임무를 할당받고 팀의 실제 구성원이 아닌 것처럼 느끼기 시작할 수 있습니다. 이는 새로운 아이디어를 제출하고 작업하는 데 동일한 도구를 사용하는 모든 사람이 완화할 수 있습니다. 예를 들어, 모든 사람이 Slack이나 다른 원격 협업 도구에 새로운 아이디어를 제출하면 원격 팀 구성원이 동등한 액세스 수준에서 토론에 참여할 수 있습니다.

팀 역학 및 역사

이전 PM이 제거되었다면 한 가지 이유는 팀을 효과적으로 관리하지 못했을 수 있습니다. 그것이 사실로 판명되면 문제의 근본 원인을 파악하고 프로젝트 인수를 팀 관계를 다시 시작할 수 있는 기회로 삼으십시오.

또한 팀 구성원 상태 및 서로 협력한 이력에 대한 모든 비공식 정보를 수집합니다. 이 암묵적인 정보는 팀의 성과 또는 부족에 대한 이유에 대한 몇 가지 핵심 통찰력을 제공할 수 있습니다. 예를 들어, 다른 사람들이 도전하기를 두려워하는 프로젝트 내 지배적인 구성원이 있다면 그것이 팀 내에서 많은 마찰의 근본 원인일 수 있습니다.

인력 및 성장 현황

프로젝트 범위, 일정 및 예산을 분석한 결과, 프로젝트 팀은 프로젝트를 완료할 수 있는 적절한 인력으로 구성되어 있습니까? 그렇지 않은 경우 상황의 원인을 찾아보십시오. 채용 과정에 방해 요소가 있을 수 있습니다. 아마도 HR은 수요가 많은 전문가를 찾지 못했을 것입니다.

이 경우 원격 전문가를 찾거나 인력 대행사에 연락하여 필요한 역할을 수행할 수 있습니다. 인력 배치는 많은 프로젝트의 주요 병목 현상 중 하나일 수 있으므로 초기에 수행하는 것이 중요하므로 프로젝트를 인수할 때 확인하는 것이 중요합니다.

프로젝트 관리자 레벨

PM에 대한 기대

회사와 프로젝트마다 프로젝트 관리자가 해야 할 일과 그 이유에 대한 기대치가 매우 다릅니다. 나중에 혼란과 의견 불일치를 피하기 위해 고객의 관점과 팀의 다른 모든 구성원의 관점 모두에서 PM에게 기대되는 것이 무엇인지 파악하는 것이 중요합니다.

예를 들어, 일부 회사에서는 프로젝트 관리자도 스크럼 마스터가 되어야 한다고 기대합니다. 이것이 별개의 역할이더라도 일부 프로젝트와 회사는 PM의 원래 직무 설명을 뛰어 넘는 기대를 가지고 있습니다. 이것은 프로젝트를 시작하기 전에 완전히 명확하지 않을 수 있으므로 일단 시작하면 이 문제를 조사하는 것을 잊지 마십시오.

프로젝트 관리자의 성과가 어떻게 측정되고 평가되는지 파악하는 것도 중요합니다. 판단할 명확한 KPI 세트가 있습니까? 아니면 이해 관계자가 사용할 유일한 성과 지표가 팀의 성공입니까? 얼마나 자주 성과 검토를 하고 멘토나 회사의 "친구"가 될 사람을 갖게 됩니까?

이는 프로젝트 관리자에게 직접 영향을 미치므로 기대에 따라 수행할 수 있도록 가능한 한 빨리 이 작업을 수행하는 것이 좋습니다.

조달 프로세스

새 팀에 어떤 백로그가 있는지에 따라 첫 날 또는 3개월 후에 조달 관련 작업에 직면할 수 있습니다. 후자의 경우라도 회사에서 조달 및 공급업체 선택이 어떻게 작동하는지에 대한 대략적인 아이디어를 갖는 것이 매우 중요합니다. 이 지식을 통해 백로그 항목과 프로젝트 일정에 대해 더 나은 결정을 내릴 수 있으며 예기치 않은 지연을 피할 수 있습니다.

회사의 규모에 관계없이 어디에도 기재되어 있지 않더라도 어느 정도 조달 절차가 있을 것입니다. 직속 상사나 다른 PM에게 벤더를 선택하고 확인하는 방법을 문의하십시오. 제안 요청(RFP)을 작성하고 지정된 기준에 따라 모든 제출물의 순위를 매긴 후 승자를 선택해야 할 수도 있습니다.

또는 프로세스가 덜 엄격할 수 있고 독립적으로 공급업체를 선택할 수 있습니다. 이 경우 이미 존재하는 벤더에 대해 주변에 물어보십시오. 팀 구성원이 여기에서 더 오래 일했지만 플랫폼의 모든 부분과 다른 팀에서 사용하는 다양한 공급업체를 인식하지 못할 수 있습니다. 또한 새로운 공급업체와 이 정보를 제공하는 방법에 대해 승인해야 하는지 직속 관리자에게 문의하십시오.

한 가지 더 주목해야 할 사항은 회사 내의 SLA(서비스 수준 계약) 기대치입니다. 프로젝트가 비즈니스 크리티컬한 경우 24시간 지원과 빠른 문제 해결 시간을 제공하는 공급업체를 찾아야 합니다. 기대치가 그렇게 높지 않다면 응답 시간이 더 긴 더 저렴한 옵션을 찾을 수 있습니다.

공급업체 목록 만들기

아직 없는 경우 프로젝트에 대한 기존 공급업체 목록을 시작합니다. 바로 100% 채우실 필요는 없습니다. 다음 필드로 새 문서를 시작하십시오.

• 이름 – 웹사이트에 하이퍼링크할 수 있습니다.
• 범주 – 처음에는 이것에 대해 너무 많이 생각하지 마십시오. 당시에 가장 의미가 있는 것을 기록하고 더 명확한 범주가 나타나면 나중에 변경하십시오.
• 간단한 설명 – 귀하 또는 다른 사람들이 공급업체가 귀하를 어떻게 지원하는지 이해할 수 있을 정도로 간단하게 작성하십시오(전자상점 결제, 인포그래픽 프리랜서).
• 공급업체 연락처 – 이메일을 분실할 수 있으므로 가까운 곳에 보관하는 것이 좋습니다.
• 내부 연락처 – 팀이나 회사에 공급업체 또는 타사 솔루션을 통합한 개발자와 계속 연락하는 사람이 있는 경우. 이것은 공급업체 및 귀사의 공급업체 참여에 대해 가장 잘 아는 사람일 것입니다.

이 목록이 있으면 각 공급업체와 관련된 프로젝트 성과를 추적하고 관리하는 데 도움이 됩니다. 또한 프로젝트의 현재 상황과 주요 병목 지점을 훨씬 더 잘 파악하는 데 도움이 됩니다.

결론

이 가이드와 체크리스트가 완전한 것은 아닙니다. 그러나 프로젝트를 인수할 때 가장 먼저 확인해야 할 사항에 대한 최상의 개요를 제공하려고 합니다. 그들 중 일부는 친숙할 수도 있고 덜 친숙할 수도 있지만, 이 모든 과정을 거치면 프로젝트를 인수할 수 있는 견고한 기반이 확보될 것입니다.

다음은 나중에 참조할 수 있도록 요약된 체크리스트입니다.

주요 시사점 – 프로젝트 인수 체크리스트