프로젝트 매니저 대응 방법과 관련하여 프로세스 영역에서 프로젝트 매니저(PM)의 케이스 별 대처에 대한 노하우는 매우 중요합니다. 프로젝트 매니저는 다양한 케이스에 따라서 적절한 대처와 대응을 할 수 있어야 합니다. 프로젝트를 진행하다 보면 다양한 상황에 직면하게 됩니다. 이러한 상황이 발생할 때 마다 체계적이고 합리적으로 대처할 수 있어야지만 프로젝트를 성공적으로 완료할 수 있습니다.
프로젝트는 대표적으로 예측형 접근 방식의 워터폴 개발 방법론을 적용한 유형과 적응형 접근 방식의 애자일 개발 방법론을 적용한 유형이 있습니다. 이 2가지 유형에 따라 프로젝트 매니저는 다른 접근 방식을 선택해야 합니다. 프로세스 영역에서 프로젝트 매니저 대응 방법에 대해서 좀 더 자세히 알아보도록 하겠습니다.
프로젝트 매니저 대응 방법에 대해 알기
프로젝트 매니저(PM)는 작업 분류 체계(WBS, Work Based Structure)의 각 작업 패키지의 자원과 기간 산정을 해야 하며 네트워크 다이어그램도 만들어야 합니다. 그 다음 프로젝트 매니저는 초기 일정을 작성해야 합니다. 프로젝트 매니저가 프로젝트의 일정을 개발하는 순서는 일반적으로 활동 정의, 활동 순서 배열, 활동 기간 산정, 일정 개발 순서입니다. 그 다음 초기 일정 작성을 해야 하는데 초기 일정은 확정된 것은 아닙니다. 초기 일정이라고 할 수 밖에 없는 이유는 만약 이 때 작성한 일정이 계약 일정이나 스폰서가 제시한 일정보다 길면 일정 단축 기법을 사용해야 하며 프로젝트 자원에서 자원에 대한 제약이 있을 경우 자원 평준화를 해야 하기 때문입니다.
프로젝트 매니저 입장에서 프로젝트 계약 기간이 정해져 있는데 특수한 상황이 발생하여 프로젝트 계약 기간 보다 좀 더 일찍 앞당겨서 오픈 해야 하는 상황이 발생할 수 있습니다. 이 때 프로젝트 매니저의 대응은 무조건 야근을 해서 앞당겨주겠다고 약속하거나 업무 범위를 줄여서 변경된 일정 계획을 다시 작성하는 방법을 사용해서는 안됩니다. 그렇다고 절대 안된다는 입장을 끝까지 고수해서도 안됩니다. 프로젝트 매니저는 먼저 팀원들과 검토 후에 일정 단축의 대안을 제시할 수 있어야 합니다.
프로젝트 매니저는 항상 팀원들과 협의를 거친 다음 여러 가지 대안을 놓고 이해 관계자들과 협의를 진행한 다음 대책을 결정하고 공식적인 절차에 의해서 계획을 변경한 후 대책을 실행하는 프로세스로 진행해야 합니다. 프로젝트를 진행하다 보면 프로젝트 스폰서가 프로젝트에 대한 자금 조달이 원활하지 않다고 이야기할 수 있습니다. 이 경우 프로젝트 매니저는 프로젝트 원가 기준선, 지출 비용, 자금 요구 사항에 대한 영향이 있는지를 살펴 보아야 합니다.
프로젝트 매니저는 요구사항 추적 매트릭스를 주기적으로 관리하여 프로젝트 팀에서 검수가 완료된 인도물을 고객에게 전달할 때 고객이 인수할 수 있습니다. 고객은 정확하게 무엇인지 모르겠지만 제품에 고객의 요구 사항이 누락된 것이 아닐까 하는 불안감이 있을 수 있습니다. 이러한 경우를 해결하기 위해서 고객과 적극적으로 소통하면서 요구 사항을 제품에 반영해야 하는 것입니다. 프로젝트 매니저는 고객이 가장 중요하게 생각하는 것은 자신의 요구 사항이 프로젝트 결과에 잘 반영되는 것이라는 점을 알아야 합니다.
프로젝트 매니저 대응의 세부 전략 이해
프로젝트 매니저(PM)는 프로젝트를 진행하다 보면 다양한 상황에 직면할 수 있고 이에 대한 대응 전략이 필요합니다. 프로젝트 착수 회의에서 발표하는 프로젝트 종료 일에 대해서 다른 의견을 제시하고 프로젝트에서 제시하는 프로젝트 일정에 동의하지 못하겠다고 한다면 프로젝트 매니저는 프로젝트 관리 계획서 승인에 고객 미 참여나 공유 누락이 문제였을 가능성이 높기 때문에 이에 맞춰서 대응을 해야 합니다. 프로젝트 착수 회의나 착수 보고의 목적 중 하나는 프로젝트 계획을 리뷰 하는 것입니다.
계획을 리뷰 한다고 해서 모든 항목들에 대해서 하나하나 검토한다는 것은 아닙니다. 각 항목에 대해 합의가 이루어진 프로젝트 계획에 대한 전반적인 리뷰를 하고 공감대를 형성하는 것을 목적으로 합니다. 따라서 착수 회의 전에 이미 일정과 같은 중요한 사항은 중요한 이해 관계자들과 합의나 공유가 완료되어야 합니다. 프로젝트 착수 회의는 일반적으로 계획 수립의 종료와 실행의 시작 단계와 관련되어 있습니다. 회의의 목적은 프로젝트 목표를 공유하고 프로젝트에 대한 팀의 헌신을 유도하면서 각 프로젝트 이해 관계자들의 역할과 담당 업무에 대한 공감대를 형성하는 것입니다.
프로젝트의 특성에 따라 다양한 시점에서 착수 회의를 진행할 수 있습니다. 소규모 프로젝트 일 경우 일반적으로 한 팀이 계획 수립과 실행을 모두 진행하게 됩니다. 이러한 상황에서는 계획 수립에 팀이 참여하기 때문에 계획 프로세스 그룹 종료 시에 프로젝트 착수 회의가 열리게 됩니다. 대규모 프로젝트에서는 일반적으로 프로젝트 관리 팀이 대부분의 계획 수립을 진행하고 나머지 프로젝트 팀원들은 초기 계획 수립의 완료와 개발의 시작 단계에 참여하게 됩니다.
이 경우 착수 회의는 실행 프로세스 그룹 초기에 열리게 됩니다. 프로젝트를 진행하는데 프로젝트가 마지막 단계에 있고 프로젝트 대금과 관련해서 착수금은 지급되었는데 중도금이나 잔금에 대해서 프로젝트 산출물에 문제가 있다고 대금 지급을 하지 않고 있는 상황이 발생할 수 있습니다. 프로젝트 매니저는 이러한 상황을 피하기 위해서 프로젝트 산출물들에 대해서 고객의 승인을 반드시 받아 냈어야 합니다. 예측형 프로젝트에서는 여러 단계들을 거치면서 생애 주기를 진행하게 됩니다.
이 경우 단계를 되돌리지 않기 위해서 단계 별로 중요한 산출물들에 대해서 승인을 받는 것이 중요합니다. 프로젝트에서는 이러한 산출물들에 대한 승인을 받아야지만 대금이 지급됩니다. 프로젝트 생애 주기에서 프로젝트 단계의 유형과 개수는 여러가지 변수에 따라서 달라질 수 있습니다. 프로젝트 생애주기 단계에 대해서 사업의 타당성 검토, 프로젝트 착수, 분석 설계, 개발과 구축, 테스트, 릴리즈, 프로젝트 종료 순서로 진행되는 경우가 많습니다. 타당성 단계에서는 프로젝트를 진행하기 위해 타당성을 검토하는 단계로 회사의 사업 계획이나 경영 계획 상 내용을 진행하기 위해서 보통 진행합니다.
회사의 경영 계획과 연결되어 있는 프로젝트 관련 문서로 비즈니스 케이스가 있는데 해당 비즈니스 케이스가 유효한지, 그리고 조직이 의도한 결과를 제공할 수 있는지 여부를 결정합니다. 프로젝트 착수는 프로젝트 계약과 동시에 진행됩니다. 프로젝트 분석 설계 단계에서는 프로젝트 계획 수립과 함께 요구사항 정의, 기획, 개발될 프로젝트 인도물들을 설계하게 됩니다. 개발과 구축 단계에서는 통합된 품질 보증 활동들을 통해서 인도물을 실제 개발하고 구축하는 것을 실행하고 진행합니다. 테스트 단계에서는 인도물에 대한 최종 품질 검토와 검사를 진행합니다.
릴리즈는 프로젝트 인도물을 실행하고 지속적이며 편익 실현과 조직 변경 관리에 필요한 이행 활동들을 완료하는 단계입니다. 프로젝트 종료는 프로젝트가 마감되고 프로젝트 지식과 인도물들을 잘 저장하고 관리하며 프로젝트 팀원들은 해산되면서 계약은 종료됩니다. 프로젝트 단계마다 다음 단계로 진행하기 전에 각 단계의 원하는 결과와 종료 기준이 달성 되었는지를 확인하기 위해서 단계 검토를 하는 경우가 많습니다. 이러한 단계 검토를 스테이지 게이트라고 부릅니다. 통과 기준은 인도물, 계약 상 의무, 특정 성과 목표 충족, 기타 유형의 측정 기준들과 관련되어 있습니다.
애자일 프로젝트의 스크럼 마스터 대응
애자일 프로젝트에서 애자일 관행들 중 지속적인 개선을 핵심 장점으로 가지고 있는 관행은 데일리 스탠드업 미팅, 반복 회고, 반복 검토가 있습니다. 데일리 스탠드업 미팅은 애자일 프로젝트 팀원들이 매일 같은 시간, 같은 장소에서 모여서 서로 마주 보는 형태로 둘러 서서 모두 서 있는 상태로 전날 진척 상황을 검토하고 오늘의 목표를 알리며 이미 발생했거나 예상되는 모든 장애 요인들을 이야기하는 일일 협업 회의 입니다. 데일리 스탠드업 미팅에서 이야기된 장애 요인들은 팀이 협력해서 해결하기 때문에 지속적인 개선 활동에 포함됩니다. 애자일 프로젝트에서의 프로젝트 매니저(PM)는 스크럼 마스터입니다.
다만, 스크럼 마스터의 역할은 다른 전통적인 프로젝트에서의 프로젝트 매니저의 역할과 상당히 다릅니다. 프로젝트에서 발생하는 장애 요인에 대해서 스크럼 마스터가 장애 요인들을 제거해주는 역할을 맡지만 프로젝트 팀이 협업 해서 진행하는 일이 많습니다. 스크럼 마스터는 단지 지원하는 역할만 담당합니다. 반복 회고의 경우는 프로세스와 제품을 개선하기 위한 목적으로 프로젝트 참가자들이 자신의 작업과 인도물을 논의하기 위해서 정기적으로 가지는 워크숍입니다. 이는 지속적인 개선에 해당합니다. 반복 검토는 반복 기간 동안 달성한 작업을 설명하기 위해서 반복 작업이 종료되는 시점에 개최하는 회의로 작업의 완료 여부를 검토할 수 있을 뿐만 아니라 이해 관계자들의 의견을 받아서 기능을 개선하기도 합니다. 반복 회고의 경우도 지속적 개선으로 볼 수 있습니다.
애자일 프로젝트에서 반복 리뷰를 진행 중인데 이해 관계자가 자신이 생각한 기능과 큰 차이가 있다고 할 경우 개발 팀은 완료의 정의(DoD, Definition of Done)를 다시 확인하고 개정해야 합니다. 반복 리뷰는 애자일 프로젝트에서 반복의 끝에 증분이 가능한지 여부를 파악하기 위해서 진행하는 관행입니다. 애자일 프로젝트에서도 이해 관계자들이 생각한 기능과 개발 팀에서 생각하는 기능 사이의 차이가 큰 경우가 있을 수 있습니다. 완료의 정의(DoD, Definition of Done)는 프로젝트 이해 관계자들이 새로운 기능에 대한 설명을 다른 방식으로 해석하여 발생할 수 있는 불일치를 방지하기 위해서 만드는 체크 리스트 입니다.
완료의 정의(DoD)는 유저 스토리가 완료로 간주되기 위해서 충족되어야 하는 기준 목록입니다. 애자일 프로젝트에서는 반복을 걸쳐서 제품을 만들고 있는데 경쟁사가 만들고자 하는 제품과 유사한 신제품을 먼저 출시하는 경우가 있습니다. 이 경우 프로젝트 매니저는 프로젝트 지속 여부를 스폰서에게 문의하여 의사 결정을 받아야 합니다. 경쟁사에서 애자일 프로젝트에서 만들고자 하는 제품과 유사한 제품을 먼저 출시하였으면 프로젝트를 계속 진행할지, 중단할지, 아니면 변경해서 진행할지를 선택해야 합니다. 프로젝트의 중단 여부를 결정하는 권한을 가지고 있는 사람은 회사에서 스폰서나 경영진입니다. 스폰서는 프로젝트에 자금과 자원을 공급하는 역할 뿐만 아니라 의사 결정을 하는 역할도 있습니다.
프로젝트 관리자 상황에 따른 대처 방법 설명
프로젝트 매니저 상황에 따른 대처 방법에 대해서 이해하는 것은 프로젝트를 이끌어 갈 때 매우 중요합니다. 프로젝트 매니저는 프로젝트를 진행하면서 다양한 상황에 처하게 될 것입니다. 이 때 마다 가장 합리적인 선택을 통해 문제를 해결해 나가야 할 것입니다. 프로젝트 매니저의 올바른 선택이 프로젝트의 성공을 좌우합니다. 프로젝트 매니저는 다양한 상황에 직면했을 때 가장 최선의 선택을 함으로써 프로젝트를 이끌어야 할 것입니다. 그럼 프로젝트 매니저의 상황에 따른 대처 방법에 대해서 좀 더 자세히 알아보도록 하겠습니다.
프로젝트 관리자 상황에 따른 대처
프로젝트 매니저는 프로젝트를 진행하는 과정에서 다양한 상황을 맞이하게 됩니다. 프로젝트들은 모두 다르고 동일한 프로젝트는 없습니다. 프로젝트들은 저마다 고유하고 유일한 특징이 있습니다. 프로젝트 매니저가 되면 프로젝트를 하나만 진행하지는 않습니다. 회사에서는 시스템 구축과 관련된 다양한 프로젝트를 지속적으로 추진하기 때문에 프로젝트 매니저가 되면 프로젝트 매니저의 역할을 계속 맡을 가능성이 높습니다.
프로젝트 관리자는 중요하고 어려운 역할이며 회사에서는 프로젝트 매니저에게 기대하는 바가 매우 클 것입니다. 하지만 프로젝트는 쉽지 않습니다. 프로젝트는 높은 기술 수준이 요구되는 업무이며 짧은 시간 안에 높은 성과를 얻기 위해서 진행하는 것이기 때문에 어려운 과제입니다. 그리고 다양한 상황에 직면하였을 때 가장 좋은 방법을 선택해서 풀어 나가야 합니다. 그럼 다양한 상황을 제시해보겠습니다. 상황 별로 프로젝트 매니저는 어떻게 대처해야 하는지 알아보겠습니다.
프로젝트가 회사에서 프로젝트를 발주하여 업체와 계약을 통해 프로젝트를 진행한다면 프로젝트를 수주 받은 업체는 수행사가 됩니다. 일반적으로 시스템을 구축하는 프로젝트의 경우 프로젝트 발주와 전문 시스템 구축 업체와 계약을 통해서 프로젝트를 진행하게 됩니다. 프로젝트를 진행하여 산출물을 만들고 시스템을 구축하는 결과를 인도하려고 하는데 고객사의 특정 이해 관계자가 프로젝트 매니저에게 외부 감사를 받지 않은 산출물과 인도물들에 대해서 승인을 하지 않겠다고 하는 경우가 발생할 수 있습니다.
이 경우 프로젝트 매니저는 품질 관리 계획서를 가장 먼저 검토해야 할 것입니다. 프로젝트 매니저는 특정 조치를 취하기 전에 발주사의 품질 정책을 재검토해야 하며 품질 정책과 품질 요구 사항을 바탕으로 프로젝트에 적용할 계획과 방법을 수립해 놓은 품질 관리 계획서를 가장 먼저 검토해봐야 하는 것입니다.
프로젝트 매니저와 이해 관계자 대응
프로젝트 헌장을 작성할 때 프로젝트를 통해서 달성하고자 하는 프로젝트의 비전과 목표를 정의하고 기술하기 위해서는 프로젝트 매니저는 전략적 계획을 참조해야 합니다. 프로젝트 매니저가 자신의 팀원들의 역할과 책임, 그리고 필요 역량에 대해서 문서화하고 이를 바탕으로 팀원에 대한 관리 계획을 수립 해야 합니다. 이 때 프로젝트 매니저는 활동 자원 요구 사항에 기재되어 있는 정보들을 참조해야 합니다. 프로젝트 팀이 프로젝트의 리스크를 관리하기 위해서 프로젝트에 영향을 줄 수 있는 리스크들을 식별하는 작업을 진행할 수 있습니다.
이 경우 전문가 판단, 데이터 수집, SWOT 분석, 대인 관계와 팀 기술, 촉발 목록, 팀 회의 등을 진행할 수 있습니다. 프로젝트 매니저는 프로젝트 방법론을 기록하고 프로젝트를 진행하는 과정에 대해서 업데이트할 수 있는데 일반적으로 프로젝트 관리 계획서에 기록하고 업데이트합니다. 프로젝트 매니저는 프로젝트 이해관계자들을 분석하기 위해서 권력과 관심도 모델을 활용하여 평가하고 분류할 수 있습니다.
만약 권력은 낮고 관심도가 높은 위치에 있는 이해관계자에 대해서는 지속적인 정보를 제공하는 방향으로 진행하는 것이 올바릅니다. 프로젝트 매니저가 과제와 과업에 대한 범위가 명확하다고 판단되어 프로젝트 진행 방식을 예측형 접근 방식은 워터폴 개발 방식을 채택하였는데 사실 알고 보니 불확실한 측면이 많다는 것을 알게 되는 경우가 있습니다. 그리고 이해 관계자들이 더 많이 참여해야 하는 사실을 알게 되었을 때 적응형 접근 방식인 애자일 개발 방식으로 변경할 수 있습니다.
이는 프로젝트 생애 주기와 관련되어 있습니다. 프로젝트가 단계 별로 진행되는데 중간에 개발 방식을 변경하게 되면 특정 단계에서 프로젝트의 스타일이 달라지는 것입니다. 프로젝트 팀이 프로젝트와 관련된 프로젝트 이해관계자들을 분석하고 어떻게 관리할 지를 분류하고 평가할 때 권력 관심도 모델 기법을 활용할 수 있습니다. 권력 관심도 모델은 이해관계자들의 권력과 관심도에 따라 철저하게 관리하거나 만족 상태를 유지하거나 정보 의사소통을 유지하거나 감시하는 대응을 하는 모델입니다.
프로젝트 매니저의 합리적 선택의 고찰
프로젝트 관리자가 프로젝트를 진행하면서 인도물을 생성하고 예산을 통제하고 품질을 보증하는 것을 철저하게 하기 위해서 다양한 도구를 사용할 수 있습니다. 가장 대표적으로 우선 순위 매트릭스를 활용할 수 있습니다. 프로젝트의 다양한 진행 과정들이 있을 때 프로젝트 매니저는 각 활동들의 우선순위를 평가한 다음 해당 결과를 반영하고 진행해야 할 것입니다. 프로젝트 팀이 프로젝트를 착수하게 되었고 프로젝트에 대한 계획이 잘 수립되었을 때 프로젝트 매니저는 프로젝트 팀과 함께 다음 단계로 진입해야 합니다. 이 때 프로젝트 매니저는 가정 제약 사항을 확인하고 작업 분류 체계(WBS)를 만들며 일정 계획을 수립하게 됩니다.
프로젝트 착수 회의에서 특정 이해관계자가 프로젝트매니저가 언급한 프로젝트 종료일이 자신이 알고 있는 프로젝트 종료일과 다르다고 말하는 경우 해당 특정 이해 관계자는 내용을 모르고 있는 상황으로 이해할 수 있습니다. 해당 이해 관계자는 프로젝트 관리 계획서에 대한 내용을 제대로 알지 못하는 것이기 때문에 해당 프로젝트 이해 관계자가 프로젝트 관리 계획서의 승인에 참여하지 않았을 것이라고 예상해볼 수도 있습니다. 프로젝트가 만약 어떠한 문제로 일정이 지연되고 있다면 프로젝트 매니저는 과거 프로젝트의 교훈을 참고할 수 있습니다.
프로젝트 상황 중에서는 외주 업체와 계약을 통해서 프로젝트를 진행하는 경우가 많습니다. 그리고 일반적으로 외주 업체는 자신들이 익숙한 시스템 환경을 사용하고 싶어하는 경향이 있습니다. 만약 외주 업체가 자신들의 시스템을 사용하고 싶다고 이야기하는 경우 프로젝트 매니저는 강요하는 선택을 하는 것이 올바를 수 있습니다. 프로젝트매니저는 긴급한 의사 결정이 필요하고 옳다고 믿는 안건에 대해서는 상급자로서의 의사 결정 상황으로 인식하고 강요할 수 있는 것입니다. 프로젝트매니저는 외주 업체를 선정할 때 공개 입찰을 통해서 업체 선정 프로세스를 업무 지원부와 함께 진행할 수 있습니다. 프로젝트 수행을 희망하는 업체가 좁혀 졌는데 후보가 되는 업체 모두 제출한 견적서와 예정 금액이 프로젝트에서 생각하는 예산 기준을 훨씬 초과할 수 있습니다. 이 때 프로젝트 매니저는 조달 협상을 진행해야 합니다.
프로젝트 매니저의 올바른 접근 방법
프로젝트를 진행하는 과정에서 프로젝트 결과물에 대해 품질 관점에서 다양한 이슈와 오류들이 발생할 수 있습니다. 프로젝트매니저는 다양한 프로젝트를 진행해본 경험이 있을 것이고 프로젝트 매니저가 과거에 진행했던 프로젝트에서도 유사한 경험이 있을 수 있습니다. 프로젝트매니저의 과거 프로젝트 경험은 교훈에 해당합니다. 프로젝트 매니저는 이전 프로젝트의 교훈을 먼저 검토한 다음 품질 관리 계획서 상에 기재되고 명시되어 있는 절차와 방법에 따라 적절한 시정 조치를 하는 것이 올바른 접근 방법입니다.
프로젝트 팀은 프로젝트 이해관계자들을 대상으로 다양한 설명 세션과 미팅을 진행할 수 있습니다. 가장 대표적으로 프로젝트 착수 회의를 진행할 수 있습니다. 프로젝트를 공식적으로 시작한다는 것을 알리는 세션이 프로젝트 착수 회의입니다. 프로젝트 착수 회의는 프로젝트의 시작인 만큼 매우 중요한 세션입니다. 이 때 프로젝트의 전략적 방향성과 사업 추진의 타당성에 대해서도 발표하고 내용을 공유할 수 있습니다. 만약 프로젝트의 전략 방향과 사업 추진의 타당성에 대한 내용이면 임원인 스폰서가 발표하는 것이 올바릅니다.
실무에서는 프로젝트 매니저가 발표할 수 있지만 이론적으로는 사업 추진의 타당성에 대해서 관리하고 의사결정하는 주체에 더 초점을 맞추기 때문에 헌장을 작성할 때 사업 추진의 타당성을 승인한 스폰서가 발표하는 것이 올바릅니다. 프로젝트를 진행하는 과정에서 회사 내부적인 사정으로 부서장이나 본부장이 프로젝트 매니저에게 프로젝트를 중단하도록 지시하고 프로젝트를 중단 시키는 경우가 발생할 수 있습니다. 일반적인 상황은 아니지만 이렇게 진행이 가능한 회사도 있습니다. 이러한 회사의 경우 조직 형태가 기능 조직 형태로 구성될 경우 가능합니다.
이는 프로젝트 매니저의 권한이 약한 것을 의미합니다. 프로젝트에서 만약 계획했던 기간 동안 하기로 되어 있는 내용이 프로젝트 일정 상 시간이 충분하지 않은 관계로 계획했던 세션에 대한 기간을 줄어야 하는 경우가 있습니다. 대표적인 예가 바로 프로젝트의 테스트 기간입니다. 프로젝트를 함께하고 있는 프로젝트 팀원들은 프로젝트 테스트 기간을 줄이자고 제안하는 경우가 발생할 수 있습니다. 그리고 이러한 제안 내용이 프로젝트 진행 상 합리적인 내용일 수 있습니다. 이 경우 프로젝트 매니저는 절차대로 진행해야 합니다. 이는 위험이 식별된 상황인 만큼 가장 먼저 위험 등록부에 등록하고 관리해야 합니다. 그리고 나서 테스트 기간을 줄여서 진행할 수 있습니다.