프로젝트 매니저 대응 전략과 진행 프로세스에 대해서 이야기해보겠습니다. 프로젝트 매니저 대응 전략과 프로세스에 대해서 이해하는 것은 프로젝트에서 매우 중요합니다. 프로젝트 매니저는 애자일 프로젝트에서는 스크럼 마스터이며 워터폴 프로젝트에서는 일반적인 프로젝트 매니저라고 부릅니다.
프로젝트 매니저는 프로젝트가 진행되는 케이스에 따라서 적절한 대응을 할 수 있어야 하고 프로젝트를 진행하기 위한 전략을 가지고 있습니다. 프로젝트 매니저는 프로젝트에서 가장 핵심적인 역할을 합니다. 프로젝트 매니저 대응 전략과 프로세스에 대해서 좀 더 자세히 알아보도록 하겠습니다.
프로젝트 매니저 대응 전략에 대한 이해
프로젝트를 진행하는데 프로젝트의 현재 위치와 단계가 전체 기간의 절반이 지나갔는데 프로젝트에서 사용한 예산이 계획보다 더 많은 돈을 사용한 경우가 있습니다. 이러한 경우 프로젝트 매니저는 예산 초과 원인을 가장 먼저 분석하는 것이 좋습니다. 문제나 이슈가 발생하였을 때는 가장 먼저 해야 할 일은 해당 문제나 이슈가 영향을 미치는 범위를 파악하고 임시 대응을 하는 것입니다. 그리고 리스크가 발생하였을 때 가장 먼저 해야 할 것은 리스크 관리 대장에 등록하고 정성적인 분석을 진행하는 것입니다.
만약 프로젝트에서 비용을 많이 사용하였다면 이는 리스크가 아니라 문제와 이슈가 이미 발생한 것입니다. 따라서 프로젝트 매니저는 가장 먼저 원인을 분석하는 것을 진행해야 합니다. 프로젝트를 진행하는데 프로젝트를 마무리하기 위한 예산이 더 필요한 경우도 굉장히 많습니다. 이러한 경우 프로젝트 매니저는 추가적인 예산을 확보해야 합니다. 예산 중에는 관리 예비를 사용할 수 있는 스폰서에게 보고를 하고 이를 확보하는 것도 하나의 방법입니다. 또 다른 방법은 변경 통제 위원회에 변경 요청을 하여 원가 기준선을 수정하는 방법이 있습니다. 하지만 변경 통제 위원회에 변경 요청을 하여 원가 기준선을 수정하는 것은 고객이나 비즈니스에서 변경 요청 때문에 원가가 증가한 것이 아니라면 진행하기 어렵습니다.
예상하지 못했던 품질 문제의 발생으로 일어난 일이라면 관리 예비비를 투입해야 합니다. 프로젝트 산출물의 품질이 중대한 어려움에 처했는데 경영진에서는 프로젝트의 가장 중요한 제약 요소가 품질이라고 하는 상황을 가정해보면 프로젝트 매니저가 가장 먼저 해야 할 것은 문제를 명확하게 정의하고 근본 원인을 해결하기 위한 원인 파악을 진행해야 합니다. 문제가 발생하면 무조건 일단 대책을 실행하는 것을 생각할 수 있지만 그것은 올바른 대응 전략이 아닙니다. 문제를 정의하고 근본 원인을 식별하는 것이 가장 우선입니다. 프로젝트에서 개발과 테스트를 완료하고 서비스의 운영 단계로 전환하려고 하는 시점인데 만약 프로젝트 팀원 중 테스트 환경과 운영 환경이 다르다는 것을 프로젝트 매니저에게 보고하였다면 프로젝트 매니저는 이슈 기록부에 등록하고 이슈 담당자를 지정하는 것이 필요합니다.
리스크는 아직 발생하지 않은 불확실한 조건이나 이벤트이며 이슈는 프로젝트 목표에 영향을 주는 현재의 조건이나 상황입니다. 만약 현재의 상황이 프로젝트 초기라고 한다면 이것은 리스크로 볼 수 있습니다. 리스크 관리 대장에 등록하고 정성적 리스크 분석과 담당자 지정, 그리고 대응 전략을 수립해서 대응해야 합니다. 현재 프로젝트의 시점이 운영 전환 시점이라면 당장 다가온 이슈이기 때문에 리스크가 아닌 이슈로 보고 접근해야 합니다. 리스크를 예방하는 것과 이슈를 해결하는 것은 다른 문제인 것입니다.
프로젝트 매니저 대응 전략과 케이스별 이해
프로젝트 팀에서는 시스템 기반의 제품과 서비스를 개발을 완료하면 테스트를 진행합니다. 테스트를 진행할 때 외부 전문가가 참여하는 테스트를 진행할 수도 있습니다. 테스트 결과 제품과 서비스에 심각한 결함이 발견 되어 프로젝트에 큰 부담이 되는 상황이라면 프로젝트 매니저는 이를 이슈 기록부에 등재하고 임시 대응책을 수립해야 합니다. 이슈 기록부에 등재 하는 것은 심각한 결함이 발견되었을 때 입니다. 이는 리스크가 아니라 이슈가 발생한 것입니다.
프로젝트를 진행할 때 만약 새로운 리스크가 발견되면 리스크 관리 대장에 등록하고 정성적 분석부터 진행하게 됩니다. 하지만 이슈가 발생하면 이슈 기록부에 등재하고 임시 대응책으로 대응해야 합니다. 임시 대응책의 경우 미리 계획하지 않은 대응책이며 예상하지 못한 위험이나 문제에 대해서 일시적인 대응책을 마련하는 것입니다. 프로젝트를 진행할 때 필요에 따라서는 다른 공급 업체를 통해서 프로젝트에 필요한 제품을 납품 받는 경우가 있습니다. 하지만 공급 업체가 불량한 제품을 납품할 수 있습니다. 이러한 상황에 대해 프로젝트 매니저가 대처하기 위해서는 반드시 조달 계약서를 확인해야 합니다.
공급 업체가 납품한 제품에 이슈가 발생하였는데 이를 해결할 수 있는 능력이 없다면 이것은 프로젝트 입장에서 이슈나 클레임이 발생한 것으로 볼 수 있습니다. 이러한 경우에는 계약서에 명시된 대로 행동하고 해결하는 것이 좋습니다. 우리나라의 계약서는 사실 이러한 부분에 대해서 비교적 간단하게 작성되어 있는 경우가 많습니다. 하지만 외국 사례를 보면 외국에서 사용하는 계약서에서는 클레임 처리에 대한 세부적인 절차와 조항들이 담겨져 있습니다. 조달 계약서 이외에 조달 관리 계획서라고 하는 문서가 있습니다. 조달 관리 계획서는 조달 프로세스 동안 수행할 활동들을 기술하는 문서입니다.
조달 관리 계획서에는 조달 이외 프로젝트 측면과 조달 프로세스를 조율할 방법이 기재되어 있습니다. 또한 중요한 조달 활동 시간표와 계약 관리에 사용할 조달 지표를 기재합니다. 조달 관리 계획서에는 프로젝트 팀의 권한과 제약을 비롯하여 조달과 관련한 이해 관계자들의 역할과 책임도 포함되어 있습니다. 프로젝트를 수행하는 회사에서 품질 정책이 있지만 품질 정책 수준이 미흡한 경우가 있습니다. 이러한 회사에서 프로젝트를 진행할 때 다른 업체와 협업하여 진행하는 프로젝트에서 다른 협업 업체의 품질 정책이 잘 되어 있는 경우도 있습니다.
발주사의 품질 정책도 잘 되어 있는 상황인 경우가 많습니다. 이러한 상황에서 프로젝트는 어떤 품질 정책을 따라야 하는지 프로젝트 매니저 입장에서는 고민이 될 수 있습니다. 발주사의 품질 정책을 사용하거나 좋은 품질 정책을 가지고 있는 협력 업체의 품질 정책을 채택해야 한다고 생각할 수 있습니다. 하지만 발주사나 협력 업체의 업종이 다르면 사용하기 어려울 수 있습니다. 따라서 수행 조직의 공식적인 품질 정책이 미흡하거나 합작 형태와 같이 여러 수행 조직이 프로젝트에 참여하는 경우에는 프로젝트 팀에서 프로젝트에 맞는 품질 정책을 개발하는 것이 올바릅니다.
프로젝트 매니저 대응 전략에 대한 설명
프로젝트를 진행할 때 분석과 설계 단계를 거쳐 개발 단계, 그리고 테스트 단계를 진행하게 됩니다. 하지만 상황에 따라서 어떤 프로젝트는 일정의 문제로 인해 개발은 진행하지만 테스트를 건너 뛰고 오픈 하는 경우가 있습니다. 이러한 상황에서 프로젝트 매니저는 가장 신경 써야 할 문제는 바로 기술 부채입니다. 테스트를 건너 뛰게 되면 개발자들이 개발한 소스 코드에 에러가 남아 있을 가능성이 매우 높습니다. 이는 나중에 프로그램에 대한 시연을 하거나 다른 프로그램들과 통합하는 과정에서 문제가 발생할 수 있습니다. 이러한 것을 기술 부채라고 부릅니다. 기술 부채는 시스템 기반의 제품과 서비스를 개발하고 구축하는 동안 정기적으로 정리와 유지 관리, 그리고 표준화를 진행하지 않아서 발생하는 작업의 백로그를 의미합니다.
프로젝트 팀에서 애자일 프로젝트를 진행할 수 있습니다. 애자일 프로젝트에서는 회고에서 새로운 장비를 도입해야 한다는 내용으로 합의가 진행되었다면 프로젝트 매니저인 스크럼 마스터는 원가를 계산한 다음 원가 기준선과 비교하여 필요할 경우 변경 요청을 통해서 장비를 구매해야 합니다. 회고에서는 프로세스 개선을 진행하게 됩니다. 비용 대비 효율적으로 진행하며 비용을 고려하지 않고 개선만 이야기하지는 않아야 합니다. 골드 플래팅이라는 개념이 있습니다. 골드 플래팅은 업무 범위가 아닌 부분을 프로젝트 팀에서 추가적으로 진행하는 것을 의미합니다. 골드 플래팅이 되면 고객 만족이 될 수도 있기 때문에 긍정적으로 생각할 수 있지만 추가적으로 진행한 업무 영역에서 법적인 문제가 발생할 수도 있고 비용과 시간이 추가적으로 소모되기 때문에 프로젝트 입장에서는 좋지 않은 것입니다. 예측형 프로젝트 방식에서의 프로젝트 매니저라고 한다면 골드 플래팅은 절대적으로 허용하지 말아야 합니다.
프로젝트 매니저는 프로젝트 팀원들과 프로젝트의 강점과 약점, 위협과 기회를 분석하고 있을 수 있습니다. 이것은 프로젝트 팀에서 리스크를 식별하는 일환 중 하나로 볼 수 있습니다. 프로젝트 매니저가 프로젝트 팀원들과요구사항들을 모아서 정의하려고 한다면 가장 먼저 관련 이해 관계자들을 식별해야 합니다. 요구 사항 수집 프로세스를 진행할 때 입력물로서 이해관계자 관리 대장이 있습니다. 이해 관계자 관리 대장이 입력물로 들어 와야지만 분류된 이해관계자 별로 인터뷰를 진행하고 설문 조사도 하고 워크숍도 진행할 수 있습니다. 요구사항 수집과 확정 프로세스는 이해 관계자를 식별하고 요구사항을 수집하며 요구사항 정의 후 작업분류체계를 생성하는 프로세스로 진행합니다.