우리는 왜 실패하였는가(pms편)

프로젝트 착수 전 단계에 고려해야 할 것들이 여러가지 있는데, 그중 프로젝트 관리 툴을 선정하는 것 또한 신중을 기해야 하고, 여러가지 선택에 있어 고려할 사항이 많다.

결국 프로젝트는 사이즈가 커지면 커질수록 관리가 어떻게 되고 있는지
모든 사람이 투명하게 볼 수 있고, 위기를 바로 식별할 수 있으며,
해결을 위해서 각각의 업무들을 담당하는 주체들이 본인이 해야 하는 일을 적시에 정확히 배정 받는 것 이 중요하다.

그래서 착수 전 PMS tool선정 시 여러가지 선택지를 두고 고민하게 되지만
이 과정에서 포인트가 빗나가면, 툴을 완전히 소화하지 못하고, 프로젝트를 이중관리 하면서
관리를 위한 관리의 늪에.. 더 정확히 엑셀 작업을 위해 PC성능을 높여야 되는 상황에 처하게 된다.

해당 과정에서 올바른 판단을 하기위해서
여러 번 반복 질문하고 명확한 답을 얻어야 하는 내용은 아래 두가지면 충분할 것 같다.

"누가 PMS를 왜 사용하는지?"
"심미성이 중요한 것인지?"

더 구체적으로 PMS에서 갖추어야 할 고려상을 정리해봤다.

PMS 갖춰야 할 것

프로젝트 계획 및 일정 [WBS]
작업관리 [테스트 일감 및 성공여부 관리]
리소스관리
협력 및 커뮤니케이션 [작업 및 이슈에 대한 알림]
예산 및 비용관리
위험관리 [이슈관리]
보고 및 분석 [보고 관리]
문서화 및 기록보관
다른 도구 통합 [팀즈 연계]


PMS가 갖추어야 하는 핵심기능
프로젝트 일정관리
프로젝트 세부 일감관리
프로젝트 이슈관리
PMS 사용자별 착안사항
개발자 : 등록하고(등록편의) / 진행상태에 대한 경고 정보 받아서 재 테스트 등이 용이하도록 해야함
관리자 : 전체 수준을 관리 (과정을 제때 알럿 받고 추가 조치) , 어느 하위 개발조직에서 문제가 있는지 식별가능해야 함
관리자 (현업) : 전체 수준을 조회하고 보고받음 (보고서와 일치 요망) / 일부 개발이나 이슈제기 등에 대한 확인필요
기존 사용상 문제점
이슈관리 : 타 커뮤니케이션 통합 불가로 시기 적절한 대응 어려움 (현업)
작업관리 : 작업 상세레벨 등록 / 조회가 어려움 (통합테스트 - 스텝 - 세부 메뉴) 중 세부 메뉴에 대한 이슈 관리가 안됨 (통합테스트 중 어느 프로그램에서 이슈가 있어서 통합테스트 실패함을 확인하기 어려움)
보고관리 : PMS 통계, 차트 등 수치를 가공하여  상이하여 이중 보고 / PMS--> 엑셀 --> PPT


PMS 선택 시 제언

PMS는 TOOl의 문제가 아니라 프로젝트 방법론의 문제로 확대해서 검토해야 한다.
우리가 프로젝트를 관리하는 방법과 상세 조건이 해당 툴에서 구현 가능한지
기존의 사용자별 불편사항을 편의적으로 개선할 수 있는지
위 조건을 해결하기 위해 기존 PMS에서 불가하거나 운영상 어려웠던 사례를 구체적으로 예시를 사전에 테스트 해보는것이 좋다
프로젝트 하위일감의 결과에 따른 상위일감 결과관리가 가능해야 한다.
Case1 : 통합테스트에서 시나리오의 성공여부를 판단할때 합/ 불 외에 조건부 패스 (중요도가 떨어지는 하위업무의 실패에 따른 전체 테스트 지연 영향도를 최소화하기 위해 어떤 하위업무의 실패 때문인지 조회/관리할 수 있도록 PMS 일감 등록, 관리가 가능한지 테스트 해봄
Case2 : 요구사항, 단위 및 통합테스트 등 해당 TASK의 핵심 ID (프로그램) 가 어떤 일감에 영향을 주는지 검색하고, 문제가 있으면 영향의 범위도 확인할 수 있어야 함 _ 프로그램 ID로 조회했을때 요구사항, 통테시나리오 등 물려있는 일감들이 모두 조회가 될 수 있다면 문제영향범위를 빨리 파악하고 일감을 분배 하기 좋음
프로젝트 과정을 보고하는 프로세스에 이중작업이 없고, 시점마다 변화하는 뷰 포인트를 유연하게 대응할 수 있어야 한다.
Case1 : 현재 단계상 가장 크리티컬한 이슈가 무엇이고, 해당 이슈를 해소하기 위한 구체적인 작업들은 무엇이며 해당 작업이 어떻게 잘 진행되고 있는지 확인할 수 있는지
Case2 : 잔여업무들 중에 우선순위가 높은 업무들은 무엇이고, 해당 우선순위를 두었을때 실질적인 진도율은 어떻게 보여주는 것이 맞는지