프로젝트 관리의 세부 내용을 소개하기에 앞서 개략적인 순서를 나열해 보자면 다음과 같습니다.
- 프로젝트 생성
- 구성원 등록
- 마일스톤 생성
- 뉴스를 통한 계획 공유
- 일감 생성
- 문서나 파일, 기타 산출물 등록
레드마인으로 프로젝트를 관리하실때 빠지기 쉬운 함정이 있습니다:
ㅁ프로젝트 구성은 단순하게, 필요한 프로젝트만
- 프로젝트 하위에 프로젝트 하위에 ... 복잡한 프로젝트 구성은 No!
- 프로젝트 찾는데 시간을 허비할 수 있다.
ㅁ레드마인 일감 흐름에 우리 구성원 업무흐름을 맞추자
- 회사의 업무프로세스를 레드마인으로 적용하는 과정에서 일감의 업무흐름을 권한에 따라 제한하지 말자. 불편하다는 사람들의 원성을 듣고싶지 않다면...
ㅁ간트차트는 참고용으로만
- 기능이 많지 않은 간트차트에 너무 연연하지 말자.
- 일정지연(붉은색)표기된 사항들에 대해서는 일감의 상세내역 파악으로 지연된 원인을 해소하고자 노력하자.
ㅁ연간/월간계획은 큰 계획 위주로
- 프로젝트 초반에 WBS 등을 운운하면서 연간/월간 계획등을 너무 많은 일감으로 구성하지 말자.
- 연간 계획은 일반적으로 20개 미만의 큰 일정만 일감을 등록하는 것이 좋다.
- 세부적인 일감은 월간/주간단위로 회의를 거치면서 하위일감으로 추가하자.
- 하위일감 담당자는 할당받은 일감을 항상 참고하고, 발생하는 이슈들은 새 일감으로 추가하거나 반드시 Comment를 남긴다.
ㅁ일감은 초등학생이 이해할수 있게 쓰자
- 업무를 잘 수행했느냐는 얼마나 일감의 갯수를 많이 처리했느냐가 아니고 업무처리 과정이 적절해야 함을 명심하자. (가장 중요!!)
- 일감은 타인(또는 팀장일 수도 있고 기술진과 관계없는 영업일 수 있다.)이 읽었을 때 진행된 업무내역 파악에 어려움이 없어야 한다
제 경험상 위에 있는 사항들만 잘 지켜져도 프로젝트 구성원은 레드마인 적용에 크게 어려움이 없을것이고, 위에 있는 사항중에 꼭 변경하고자 하는 내용은 구성원들이 충분히 숙달된 다음에 반영해도 늦지 않을 것입니다.
레드마인이 프로젝트 관리에 잘 적용되었다/그렇지 않다는 아래와 같은 사례로서 짐작할 수 있겠습니다.
레드마인 숙달이 잘 된 경우 일어나는 일들:
레드마인이 프로젝트 관리에 잘 적용되었다/그렇지 않다는 아래와 같은 사례로서 짐작할 수 있겠습니다.
레드마인 숙달이 잘 된 경우 일어나는 일들:
- 프로젝트의 주요 이벤트가 구성원에게 잘 전파되어 그런 얘길 처음 듣는다는 직원이 줄어든다.
- 다른 직원에게 업무를 요청해야 하는 경우 간략한 설명을 전화로 하고, 상세 내용은 레드마인을 통해 전달하는 장면을 자주 목격한다.
- 문서의 공유가 레드마인을 통해 이루어 지고 공유된다.
- 일감의 내용에서 정성 정성 정성... 정성스러움이 한눈에 보기에도 드러난다.
- 일감들의 해결 현황이 그래프를 통해 확인 가능하다.
- 주간/월간회의때 레드마인을 크게 띄우고 회의한다.
반대로 숙달이 잘 되지 않은 경우 일어나는 일들:
- 일감이 닫히지 않은 상태로 방치되어 있다. 예를들면 생성날짜가 3개월전인데 이렇다할 Comment하나 없다.
- 프로젝트 내 전체공유 알림을 날려도 그런 얘길 전달받은 적이 없다는 사람이 열에 다섯 이상 된다.
- 문서 공유가 되지 않아 보통 메일로 전달받는다.
- 일감이 한줄로 띡... 도저히 업무내용을 알수 없다.
- 알감 해결현황 트랜드 그래프가 줄어들지 않는다.
- 주간/월간회의때 엑셀/워드로 공유하고 있다.
프로젝트 관리도구는 함께하는 구성원이 모두 활용할때 빛을 발하지만, 일부 구성원이 불편하다, 기능이 너무 많다 등의 변명을 늘어놓을 때는 오히려 독이되기 쉽습니다. 5명 미만의 소 그룹에서는 프로젝트 관리에 레드마인 도입을 더 신중히 생각해 보셔야 겠는데요. 5명 이상 넘어가는 그룹에서 구성원간에 커뮤니케이션이 동반되어야 하는 프로젝트라면 그 중요성을 더 크게 느낄 수 있을 거라 생각합니다^^
감사합니다. 많은 도움이 됐습니다.
답글삭제