프로젝트 노하우와 프로젝트를 체계적으로 접근하기 위한 전략은 매우 중요합니다. 프로젝트 매니저는 프로젝트를 진행할 때 자신만의 노하우를 가지고 있어야 하며 프로젝트를 체계적으로 접근하기 위해서 프로젝트와 관련된 가이드를 숙지하고 절차와 규정에 따라 움직여야 할 것입니다.
프로젝트를 진행하게 되면 다양한 상황에 직면하게 됩니다. 이 때 마다 프로젝트 매니저는 합리적인 선택을 통해서 문제를 해결해나가야 합니다. 프로젝트 매니저는 문제를 해결하는 역할을 맡습니다. 따라서 프로젝트 매니저는 문제를 해결하기 위한 체계적인 접근 방법을 잘 알고 있어야 합니다. 프로젝트 노하우와 체계적인 접근 방법과 전략에 대해서 좀 더 자세히 알아보도록 하겠습니다.
프로젝트 노하우와 대응 전략 설명
프로젝트 매니저는 프로젝트를 진행하면서 다양한 상황을 직면하게 되고 이를 통해 문제를 해결해야 하는 역할을 담당하게 될 것입니다. 따라서 프로젝트 매니저는 다양한 상황들에 대해서 어떻게 대처하는 것이 합리적이고 올바른지를 잘 알고 있어야 합니다. 이를 위해서는 다양한 케이스 별 대응 방법에 대해서 공부하고 숙지하는 것이 좋습니다. 프로젝트를 진행할 때 동일한 문제가 발생하지 않을 수도 있지만 다른 프로젝트에서 발생했던 동일한 문제가 발생하는 경우가 더 많습니다. 이 때마다 새로운 창의적인 접근 방식을 적용하는 것이 아니라 가장 모범적인 대응 방안을 선택하여 문제를 해결해야 합니다.
프로젝트 팀이 제품의 기능을 평가하기 위해서 상대적 가중치 접근 방법으로 작업을 진행하고 있는데 제품의 기능에 대해서 고객에게 편익을 강조하고 가치를 제공하기 위한 방향으로 개발에 대한 우선순위가 정해져야 할 것입니다. 이 때 프로젝트 팀은 프로젝트 매니저에게 조정과 협업 작업에 대한 요청이 있을 것입니다. 프로젝트 매니저는 프로젝트 팀의 이러한 요청에 응답해야 합니다. 적절한 조정을 통해 프로젝트가 올바른 방향으로 갈 수 있도록 인도하고 프로젝트를 통해 고객에게 편익을 강조하고 가치를 제공할 수 있도록 결과를 만들어야 할 것입니다.
프로젝트 매니저는 매트릭스 조직하여 가상 팀으로 개발 프로젝트를 진행하는 경우도 있을 수 있습니다. 이 경우 프로젝트 팀을 구성하기 위해서 각 기능 관리자인 각 부서의 부서장으로부터 프로젝트 팀에 투입될 인력을 제공 받아야 합니다. 이 과정에서 프로젝트 매니저는 기능 관리자와 다양한 마찰이 발생할 수 있습니다. 각 부서의 부서장은 일반적으로 인력을 주기 싫어하고 가용 가능한 인력이 없다고 대응하는 경우가 많습니다. 프로젝트 매니저는 이러한 상황에서 필요한 인력과 자원을 얻기 위해서 전략적으로 행동해야 합니다. 가장 먼저 프로젝트 매니저는 필요한 인력을 얻기 위한 세부 사항을 논의하기 위해서 기능 관리자와 협의 과정을 먼저 진행해야 합니다.
프로젝트 노하우와 케이스별 대응 방안
프로젝트 매니저와 프로젝트 팀에서는 여러 명의 내부 이해관계자들과 외부 이해관계자들로 구성된 대규모 프로젝트를 진행할 수 있습니다. 초기 영향도 분석 단계에서 새로운 개발 반영 사항들과 여러 개의 시스템 구조를 식별할 수 있습니다. 여러 개의 시스템 구조를 갖추고 있을 경우 다양한 사용자들의 이해 관계와 연결될 수 있습니다. 초기 설계 단계의 진행 과정을 마무리한 다음 프로젝트 팀은 여러 개의 시스템과 관련된 사용자들의 유형을 더 잘 이해하기 위해서 회의와 미팅, 인터뷰, 브레인 스토밍 등 다양한 세션들을 진행할 수 있습니다. 이는 사용자에 대한 페르소나를 설정하고 이해하기 위해서 입니다.
이를 통해 프로젝트를 더 원활하고 목적에 맞게 진행할 수 있게 됩니다. 페르소나는 특정 사용자의 유형을 표현할 수 있는 가상의 대표 캐릭터이며 데이터를 기반으로 만들어지는 개념입니다. 페르소나는 사용자에 대한 공감대를 형성할 수 있도록 도와주며 사용자들의 필요와 니즈, 그리고 프로젝트에 대한 기대를 이해할 수 있게 해줍니다. 회사에서 프로젝트를 진행하다 보면 프로젝트 매니저가 교체되는 경우도 있습니다. 특히 수행사의 프로젝트 매니저는 고객사와의 마찰이 있을 경우 고객사의 의지에 의해서 교체되는 경우도 있습니다. 프로젝트 진행 도중에 프로젝트 매니저가 교체되어 새로운 프로젝트 매니저가 투입되었다면 해당 프로젝트 매니저는 가장 먼저 이해관계자들에게 프로젝트 편익을 제시해야 합니다.
프로젝트 매니저는 프로젝트의 편익을 제시할 때 예상되는 비즈니스 가치를 설명하는 것이 좋고, 프로젝트 전반에 걸쳐서 편익을 측정하는 지표를 제시하고 목표한 편익 달성과 관련된 제약 사항과 리스크를 발표하는 것이 좋습니다. 프로젝트 시작 단계에서는 프로젝트 관리 계획을 개발하고 프로젝트 관리 계획서를 작성해야 합니다. 프로젝트매니저는 산출물과 인도물의 목록을 작성하고 이를 조정 과정을 통해 회사에서 요구하는 규격에 맞춰야 하며 상위 수준의 비즈니스 요구 사항에 대해서는 명확화를 진행해야 합니다. 프로젝트 관리 계획서에는 범위 기준선이 반영되며 이를 위해서는 상위 수준의 프로젝트 요구 사항들이 명확해져야 합니다. 프로젝트를 실제 실행하는 단계에서 새로운 프로젝트매니저로 교체되었다면 해당 프로젝트매니저는 프로젝트의 상황과 프로젝트 팀에 빠르게 적응해야 합니다.
프로젝트매니저가 교체가 되었는데 오히려 팀 성과가 감소하고 프로젝트 핵심 성과 지표에도 문제가 발생하고 있다면 안됩니다. 따라서 이러한 신규 프로젝트매니저는 이러한 상황을 극복하고 개선하기 위해서 가장 먼저 성과가 낮아지고 있는 근본적인 원인들을 파악해보고 팀 회의를 소집하여 문제를 해결하기 위한 방안들을 강구하고 실행해야 합니다. 이는 성과 개선을 마련하기 위한 방법을 만드는 것과 관련되어 있습니다. 모든 일이 그러하듯이 개선을 위해서 가장 먼저 해야 할 것은 원인 분석입니다. 프로젝트매니저의 역할은 매우 무겁고 어렵다는 것은 회사에서도 이해하고 인정해야 할 것입니다.
프로젝트 노하우를 통한 효과적인 대응
프로젝트 매니저는 프로젝트 이해관계자를 식별하는 작업을 진행해야 합니다. 프로젝트 매니저가 프로젝트의 주요 이해관계자들을 식별하기 위한 세션을 모두 마무리하였다면 그 다음으로 해당 이해관계자들을 분석해야 합니다. 프로젝트 이해관계자와 관련된 문서로는 이해관계자 관리 대장과 이해관계자 참여 계획서가 있습니다. 프로젝트 인도물에 대해서는 워크샵을 통해서 검토하고 후속 조치에 대해서 검토할 수 있습니다. 만약 실제 후속 조치 항목들이 만들어졌다면 프로젝트매니저는 프로젝트 팀과 함께 조치에 대한 우선순위를 정하고 해당 과제를 완료하고 책임질 수 있는 담당자를 지정하며 진행 상황에 대해서 모니터링 해야 합니다.
프로젝트 중 과거의 유사한 프로젝트 경험을 기반으로 이와 비교하였을 때 중간 수준의 복잡성을 가지고 있는 프로젝트를 진행하기로 결정할 수 있습니다. 프로젝트 유형 중에 시스템 유형이 내부 직원들이 사용하는 시스템이어서 가시성이 낮은 경우도 있고 반대로 대고객을 대상으로 하는 시스템이어서 가시성이 높은 경우도 있습니다. 프로젝트를 통해 시스템 기반의 제품과 서비스를 개발하고 구축하고 이를 고객이 즉시 사용할 수 있도록 인도해야 하는 프로젝트인 경우 상당히 어렵고 중요도가 높은 프로젝트가 됩니다. 프로젝트 매니저는 이러한 프로젝트를 진행할 때 프로젝트 생애 주기에 걸쳐서 일정 관리와 이해 관계자들의 참여에 보다 적극적으로 대응해야 할 것입니다.
프로젝트 매니저는 프로젝트 팀원들도 관리해야 합니다. 프로젝트가 발주사와 수주사의 관계로 발주사는 고객사가 되어 프로젝트를 수주하는 수주사와 함께 협업 하는 구조의 프로젝트로 진행될 경우 수행사 입장에서는 고객사의 요구 사항을 구현하고 개발하는 역할을 맡게 됩니다. 이러한 경우 수주사에서는 프로젝트를 진행하기 위해서 다양한 방법으로 개발 인력을 동원하게 됩니다. 수주사에서는 프로젝트 개발 인력 중 핵심 개발자도 전략적으로 투입 시키게 됩니다. 그리고 고객사의 직원들과 협업해서 프로젝트를 진행하게 됩니다. 이 과정에서 고객사의 직원과 프로젝트 투입 인력과 마찰이 발생할 수 있습니다.
고객사 입장에서는 특정 인력과는 더 이상 프로젝트를 같이 하고 싶지 않다고 통보하는 경우도 있습니다. 이는 계약서 상에도 명시되어 있기 때문에 고객사가 완강할 경우 프로젝트 매니저는 이를 수용해야 합니다. 다만, 대상이 된 개발자가 프로젝트 내에서 중요한 역할을 담당하고 있는 경우가 있을 수 있습니다. 이러한 경우 프로젝트 매니저는 먼저 해당 이슈를 평가해보고 다음 단계를 결정하기 위해서 다시 고객사와 고객사 직원, 그리고 문제가 된 개발자와 별도로 대화를 진행해야 합니다. 만약 풀 수 있는 문제라면 풀어 보는 것도 좋은 방법이 될 것입니다. 프로젝트 매니저는 프로젝트 노하우를 통해 효과적으로 대응해야 할 것입니다.
프로젝트 매니저의 합리적인 선택 문제
프로젝트가 종료 단계에 있어 막바지의 마무리 단계에 있는 상황에서 발생할 수 있는 문제를 생각해볼 수 있습니다. 만약 프로젝트 이해 관계자들 중 고위 직책을 가지고 있는 이해 관계자가 프로젝트 매니저에게 매우 중요한 요구 사항이 프로젝트 범위에 포함되지 않아 시스템을 오픈 하더라도 비즈니스 관점에서 가치를 제공할 수 없을 것이라고 이슈를 제공하는 상황이 발생할 수 있습니다. 이러한 경우 프로젝트 관점에서는 매우 큰 문제가 됩니다. 프로젝트 매니저는 가장 먼저 새로운 요구 사항이 추가되었을 때 프로젝트의 성과에 미칠 영향을 가장 먼저 평가해야 합니다. 그리고 나서 후속 대응 방법을 고민해야 할 것입니다.
다만, 무조건적으로 해당 요구 사항을 프로젝트에 포함 시키게 되면 새로운 문제를 야기할 수 있기 때문에 전략적이고 신중하게 접근해야 할 것입니다. 회사 내에서 권력과 힘을 가지고 있는 프로젝트 스폰서에게 상황을 알리고 지원을 요청하는 것도 하나의 방법이지만 이는 나중에 진행할 수 있는 옵션 중 하나입니다. 프로젝트 매니저는 프로젝트 유형 중 조직의 혁신과 관련된 프로젝트를 진행 해야 하는 경우도 있습니다. 조직의 혁신과 관련되어서는 일반적으로 회사에서 연초에 개별적인 성과 계획을 정의하고 수립하며 부서장들이나 본부장들이 연말에 성과에 대해서 확인하고 검토하게 됩니다.
이 경우 프로젝트에서는 프로젝트 내부적으로도 성과에 대해서 확인하고 논의할 수 있습니다. 만약 당해 연도에 개별 성과 계획에 포함된 내용과 작업 된 내용과 일치하지 않는 점들이 발견되면 프로젝트 매니저는 이러한 결과 보고를 바탕으로 기대 빈도에 대해서 확인하고 조율하기 위해서 부서장들과 다시 논의하고 대응책을 마련할 수 있습니다. 물론 이러한 상황이 발생하지 않도록 프로젝트매니저는 프로젝트를 통해 진행하고자 하는 과제들이 성과와 잘 연결되는지 지속적으로 확인하고 모니터링 해야 할 것입니다.
이러한 문제는 빨리 발견되면 될 수록 좋은 것입니다. 프로젝트 범위도 프로젝트에서는 매우 중요한 사항입니다. 프로젝트 범위에 대해서는 프로젝트 초반부터 명확하게 정의되어야 하는데 프로젝트 이해 관계자가 프로젝트 매니저에게 계약서에 요청된 기능과 다르다고 이의 제기를 할 수 있습니다. 프로젝트매니저는 해당 내용들이 문서화 되어 있는지를 가장 먼저 확인해야 합니다. 프로젝트의 문서 중 제안 요청서, 제안서, 수행 계획서, 요구사항정의서, 화면설계서와 같은 문서에 내용이 기재되어 있어야 진행할 수 있는 근거가 됩니다. 프로젝트 매니저는 이러한 사항을 잘 이해하고 있어야 합니다.